Nested public imports - bug or feature?

[Jonathan M Davis via Digitalmars-d]

On Thursday, 13 August 2015 at 15:49:10 UTC, Dicebot wrote:
> On Thursday, 13 August 2015 at 15:40:12 UTC, Timon Gehr wrote:
>> You know about static imports, right?
>
> Yes, as well as about renamed and selective ones ;)
>
> Problem with static imports is that they are all-or-nothing. 
> And in our projects it is common to have module names with 5 
> nested packages or even more. Typing all of it is impractical - 
> simple prefix gives enough protection from random clashes.
>
>>> D module system is completely broken in that regard.
>>
>> What's the alternative?
>
> When doing my old "Rust vs D" comparison I have been mentioning 
> their import semantics as a big win. When you do import like 
> this:
>
> use phrases::english::greetings;
>
> You must always also qualify symbol name with module name like 
> this:
>
> println!("Hello in English: {}", greetings::hello());
>
> And this won't compile:
>
> println!("Hello in English: {}", hello());
>
> It has similar benefits as the idiom proposed in this topic - 
> greatly reduced risk of accidental clashes.

You can get that behavior with static imports in D, but having to 
use the whole import path while referencing symbols gets ugly 
fast. There's a reason that using directives get used heavily in 
C++, though at least there, if you're behaving yourself and not 
using using directives in .h files, that doesn't affect 
#includes, unlike with D's import (though having to fully qualify 
everything in header files is always annoying). But you still end 
up with potential breakage in .cpp files due to new symbols being 
introduced which clash.

I honestly don't see a good solution to the problem, because 
requiring that you fully qualify symbols is incredibly annoying 
and hideous, but if you don't, then adding symbols to a module is 
always going to break code. As far as I can tell, your module 
system is stuck with one poison or the other. Maybe something 
similar to using directives that didn't leak outside of the 
module would be a reasonable compromise, but then many folks 
would just have a using directive for every import in order to 
avoid having to fully qualify symbols. So, I really don't see a 
good solution, and while the potential breakage caused by D's 
solution is annoying, I'd much rather have that then be forced to 
use fully qualified names.

- Jonathan M Davis