Pathological import symbol shadowing

H. S. Teoh hsteoh at quickfur.ath.cx
Sat Nov 21 17:57:51 UTC 2020


On Fri, Nov 20, 2020 at 06:25:59PM -0800, Walter Bright via Digitalmars-d wrote:
> On 11/17/2020 5:28 PM, Timon Gehr wrote:
[...]
> > It's a prototypical example of symbol hijacking. std.file.write
> > hides std.stdio.write. Therefore, the code above overwrites the
> > contents of the file "important_data.txt" with the string " read
> > sucessfully!\n".  The code should result in an ambiguity error as
> > there are matches in two distinct overload sets.
> 
> That isn't hijacking, it's scoping.  Hijacking is when an overload is
> added to one module that is accidentally a better match than unrelated
> overloads in another module, when both are in the same scope.

The problem is that this concept of scoping is very counterintuitive:
object.get is (implicitly) imported at module scope.  Then std.curl.get
is imported in function scope.  When `get` is referenced, std.curl.get
gets tried first, which is expected.  But failing that (because the
arguments don't match std.curl.get), one expects the compiler to
fallback to the parent scope and try object.get, since, after all, the
arguments obviously don't match std.curl.get, the user probably meant to
call a different `get` that's in scope.  However, the compiler bails out
with an error instead.  The overall appearance is, std.curl.get has
hijacked object.get.

It may not *technically* be hijacking, but it certainly looks like it,
feels like it, and smells like it.


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond


More information about the Digitalmars-d mailing list