local import hijacking

[Joakim via Digitalmars-d]

On Monday, 18 January 2016 at 17:02:07 UTC, Jack Stouffer wrote:
> On Monday, 18 January 2016 at 14:01:15 UTC, rsw0x wrote:
>> one of the biggest things D has over C++ is its vastly 
>> superior module system.
>
> When you compare D's something with C++'s nothing, then the 
> module system in D is infinitely better by definition.
>
>> Is there a compiled list of issues?
>
> 1. As deadalnix pointed out, a lack of spec
>
> 2. Issue 313
>
> 3. Issue 314
>
> 4. Issue 10378
>
> These are the biggest IMO. There are probably others I don't 
> know of.
>
>> I'm not sure I agree on 'half finished'
>
> When looking at the above issues, it becomes clear that the D 
> module system does not completely provide one of the main 
> things module systems are designed for: encapsulation.

The problem is that D's import system is much more advanced than 
those in C++ or Java, allowing much more control and precision 
over what's imported, so some leaks have sprung in D's more 
complex module implementation.  Certainly much more than half, 
but definitely not finished. :)

If you simply stick a bunch of non-selective imports at the top 
of a module, ie non-local, and all the modules you import do the 
same (this is tougher, as not everybody is aware of the issue and 
some library might leak symbols into your module if they're not 
as conservative), you'll have no problem.  If you use more 
advanced features like selective or local imports, there are a 
few places they leak symbols or can shadow variables in 
non-intuitive ways, as the issues you listed enumerate.