On 08/13/2015 05:35 PM, Dicebot wrote:
> On Thursday, 13 August 2015 at 13:42:42 UTC, Jonathan M Davis wrote:
>> I confess that I don't particularly like that this is legal (and I
>> think that public imports tend to get a bit hinky because of the fact
>> that they create aliases), and I'm not quite sure how you could use it
>> form "import hygiene," but I also don't see how this could work any
>> other way if scoped, public imports are allowed.
>
> It won't work if you define importing as adding module to internal scope
> symbol lookup table, without actually adding imported symbols to scope.
>

It's about _public_ imports, which are special. (Also, you don't need to "actually" add imported symbols to any scope. The "redirect" method also works for '.' access.)

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.

On 08/13/2015 05:34 PM, Dicebot wrote:
>
>> In any case, I guess we agree that this idiom should work for public
>> imports, but not for non-public ones (so the current behaviour with
>> non-public imports is accepts-invalid, but Dicebot's code should be
>> fine)?
>
> I am very curious to learn "official" answer :)

If there is only one sane/consistent/turtles/etc choice for the behaviour of some feature, typically, assuming that /eventually/ this choice will be made works.

On Thursday, 13 August 2015 at 15:29:19 UTC, Dicebot wrote:
> struct Something
> {
>     public import a;
> }
>
> void main() { Something.foo(); }

What's wrong with `import Something = a;`? Bugs?

On Thursday, 13 August 2015 at 15:53:16 UTC, anonymous wrote:
> On Thursday, 13 August 2015 at 15:29:19 UTC, Dicebot wrote:
>> struct Something
>> {
>>     public import a;
>> }
>>
>> void main() { Something.foo(); }
>
> What's wrong with `import Something = a;`? Bugs?

Even better: feature.

On 08/13/2015 05:49 PM, 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.

(Which is an arbitrary restriction most likely motivated by implementation difficulties.)

> 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.

static import greetings=phrases.english.greetings;

?

On Thursday, 13 August 2015 at 15:53:16 UTC, anonymous wrote:
> On Thursday, 13 August 2015 at 15:29:19 UTC, Dicebot wrote:
>> struct Something
>> {
>>     public import a;
>> }
>>
>> void main() { Something.foo(); }
>
> What's wrong with `import Something = a;`? Bugs?

Works only with a single import:

import mypkg = mypkg.mysubpkg.mod1;
import mypkg = mypkg.mysubpkg.mod2; // error, can't redefine aliased import!

struct mypkg
{
    import mypkg.mysubpkg.mod1;
    import mypkg.mysubpkg.mod2; // fine
}

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

On Thursday, 13 August 2015 at 15:59:46 UTC, Timon Gehr wrote:
> On 08/13/2015 05:49 PM, 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.
>
> (Which is an arbitrary restriction most likely motivated by implementation difficulties.)

Well I prefer to work with tools I have right now and not wait for something sane to be implemented.

> static import greetings=phrases.english.greetings;
>
> ?

http://forum.dlang.org/post/szaaakmavraxatkrfpnx@forum.dlang.org

On Thursday, 13 August 2015 at 16:19:29 UTC, Jonathan M Davis wrote:
> You can get that behavior with static imports in D, but having to use the whole import path while referencing symbols gets ugly fast.

Check example again, you are only required to use the plain module name, not fully qualified one. With D syntax:

import std.stdio;

writeln(); // not good
stdio.writeln(); // good
std.stdio.writeln(); // also good, but not required