[frustration, sorry] Import conflict madness.

[Jari-Matti Mäkelä]

Chris Miller wrote:

> Here's a simple example of the issue:
> 
> 
> // -- foo.d --
> private import std.stdio;
> 
> 
> // -- bar.d --
> private import std.stdio;
> 
> 
> // -- test.d --
> 
> import foo, bar;
> 
> void main()
> {
>      char[] hi = std.string.toString(3);
> }
> 
> 
> DMD 0.160:
>     foo.d(1): import foo.std conflicts with bar.std at bar.d(1)
> 
> 
> Of course, the code in test.d is a mistake, but look how unhelpful the
> error message is. It will blame a library's code for a mistake the
> library-user made.
> 
> Also notice that it's considering *private* imports, which shouldn't even
> be available to test.d.

The compiler should say something like "function module1.foo is private and
thus cannot be used in module2", when it's not accessible.

The annoying thing is that when there's a function name conflict and the
first conflicting function is privately imported and the other is publicly
imported, the public version does not override the private one. And when
the same symbol is imported using 2+ import routes, there's the same old
bogus naming conflict again.

-- 
Jari-Matti