On 11/17/2020 5:28 PM, Timon Gehr wrote:
> On 18.11.20 02:11, Walter Bright wrote:
>> On 11/15/2020 6:24 AM, Timon Gehr wrote:
> There is no collision with proper overload resolution. The error is spurious.

Reasonable people can disagree over what "proper" overload resolution is.


> What kinds of special cases have been added, by the way?

I don't remember the details, it was several years ago. And the fact that I don't recall the details suggests it is more complex than necessary. I was aiming for something better than C++ where perhaps 1 in 10,000 C++ programmers can actually explain why one symbol is preferred over another, the other 9,999 just try random things until they get what they want.

That I've failed at that is disappointing. But I also know that endlessly tweaking it to find the "proper" solution means endlessly breaking existing code in mysterious ways.


> I think that's not true in this case. (As I know you are aware, hijacking protection is designed precisely to avoid breaking code in mysterious ways!)

And it's been mostly successful at that. But even if it isn't, suddenly breaking existing code doesn't please users.


>> Please elaborate on what is invalid about it? Don't make me guess!
> 
> 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.

On Friday, 13 November 2020 at 22:57:03 UTC, H. S. Teoh wrote:
> Just ran into this today:
>
> 	void main() {
> 		int[string] aa;
> 		int x;
>
> 		x = aa.get("abc", 123);	// OK
>
> 		import std;
> 		x = aa.get("abc", 123);	// Error: template std.net.curl.get cannot deduce function from argument types ...
>
> 		import std, object;
> 		x = aa.get("abc", 123);	// OK
> 	}

Can we fix this particular case by adding "public import object;" to std/package.d ?

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

On 21.11.20 03:25, Walter Bright 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.

You can have three modules where module `A` imports module `B` and `C` and if I add a symbol `foo` in module C, some lookup in `A` changes from `B.foo` to `C.foo`. I'd call that hijacking: You have a relationship between modules `A` and `B` that is intruded upon by some unrelated change in module `C`. (Anyway, my point was actually that this is bad, not that it should be called hijacking. It's even bad for the same reason "overload" hijacking is bad.)