[frustration, sorry] Import conflict madness.

[Jari-Matti Mäkelä]

Deewiant wrote:

> Dawid Ciężarkiewicz wrote:
>> Imports probably, but ... why? It takes 15 minutes of frustrating
>> checking your files. You seek help on #D irc channel (nice people BTW) -
>> but they can not help you. They can only tell "It might be that in some
>> unrelated file you are trying to use map without importing map but are
>> importing files that do import map" which is great help but still will
>> require you to spend great amount of time finding this place.
>> 
> 
> Seems to me that using "private import" instead of "public import" (the
> default) might help in locating this. When using "private import A;" in a
> module B, any other module that imports B does not automatically import A.

I'm not that sure about that. This might be an oversimplified case, but I
think the problem comes up, when (A,B,C,D are modules here) B and C
(privately) import A, and D imports both B and C. Now DMD regards function
foo() in module A as B.foo() and C.foo() through the import chains. When D
imports both B and C and a name conflict comes up, since they can't both
become D.foo().

Ok, how do we fix this problem? A proper way to handle these would be IMO to
save full info about the symbols and their origins in the symbol table. I'm
not a compiler writer and haven't had much time to find out how this is
done at the moment. But as a workaround you can (private) import B in
module C. After that there's only one route to the symbol source.


> I have long felt that private should be the default.

Yes. But imports should work properly, too.

-- 
Jari-Matti