Pathological import symbol shadowing
newshound2 at digitalmars.com
Sat Nov 21 02:25:59 UTC 2020
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.
More information about the Digitalmars-d