Pathological import symbol shadowing

[Walter Bright]

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.