--- Comment #23 from Jonathan Marler <> ---
> I have not thought about this thoroughly, but I suspect the core of a fix can 
> be along the lines of detecting that an explicit import of bar.d is done 
> using two different names in the same module.

I think you'll find that this is "easier said than done".  The name that was
used to import a module is no longer available once the import is processed. 
The compiler just adds the module to the proper location in thy symbol table
and moves on.

Essentially, you need a way to reverse a symbol lookup.  You need to be able to
take a Module object and lookup the name that was used to import it.  This will
require either a new list field for all imports, or a new list field for all
"importees", or you will need to walk the entire symbol table tree every time
you want to check if there is a conflict.

The place in the code where you would perform this check is in `dimport.d` in
the load function.  Near the top of the funciton there is a branch `if
(s.isModule()), and you can insert the check right there.

However, I don't know why we would go through all the trouble to support this.
You'd be adding a fair amount of runtime overhead for every import statement or
more memory to cache the reverse lookups.  Not to mention the extra complexity
this is going to introduce.  And the use case where this actually works is so
narrow, it only works if the module are not compiled in the same compiler


Reply via email to