imports - 2 years later

[Ant]

Jari-Matti Mäkelä wrote:
> Ant wrote:
>> Walter, we still have:
>>
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>>
>>
>> these are both private import std.string;
>>
>> the interesting thing is that I had a
>> private import std.c.stdio;
>> in one module that would supply std.string to a bunch of other modules
>>
>> well, I know you cannot do anything about this
>> and I know I cannot reduce this problem... but it's better than 2 year
>> ago! :)
> 
> I think the problem is that DMD tries to be more intelligent than it
> really is. It saves the private symbols in the symbol table too, but is
> unable to hide them, when a public one should "mask" them. Another
> problem is that when the same module is imported using two different
> "routes", DMD is unable to determine, whether these modules are the same
> ones.

I think that a valid hypotheses clearly explained.
But what matters is what Walter will do about it.

Thank you,

Ant