On Thursday, 13 August 2015 at 16:40:31 UTC, Dicebot wrote:
>
> Matter of scale. At some point of application size maintenance cost become much higher than development costs - and problems of name clashes become more important than any extra typing annoyance.
>
> In my C++ projects such "using" abuse was normally banned.

I would add that it's not just C++. It is also common in Python to use the full name, albeit typically with an alias, e.g. import numpy as np. One benefit of this approach is that you can easily find every function using numpy in a file.

So, while I'm sympathetic with Jonathan's point about requiring the module being a little annoying if you're doing something small, I think you raise a good point about large projects. Nevertheless, others have already pointed out options for allowing the control that you need.

If you think that you should be able to re-define imports, then submit an enhancement request. I looked for any suggesting it, but didn't see anything.

I did see a few others related to imports that were interesting like allowing something like

import std {
     array, range;
}

On Thursday, 13 August 2015 at 17:51:06 UTC, Jonathan M Davis wrote:
> But the private symbols affecting the public API is just plain embarrassing and definitely makes the problem _far_ worse.
>
> - Jonathan M Davis

It's worse than embarassing. Every symbol added, public or private, must be considered a breaking change.

On 08/13/2015 06:36 PM, Dicebot wrote:
> On Thursday, 13 August 2015 at 16:24:56 UTC, Timon Gehr wrote:
>>>> static import greetings=phrases.english.greetings;
>>>>
>>>> ?
>>>
>>> http://forum.dlang.org/post/szaaakmavraxatkrfpnx@forum.dlang.org
>>>
>>
>> How is this relevant? Does Rust support it?
>
> Relevant as explanation why I don't consider aliased imports a solution.
>
> Rust does exactly that and I feel that "bottom-qualification" is
> inferior approach to "top-qualification" in general for deeply nested
> package hierarchies. Of course, both are much more hygienic than
> semantics D uses by default

I am unable to understand your concerns precisely, because you are making up words without giving definitions or examples.

https://www.google.ch/search?q=module+system+bottom-qualification
https://www.google.ch/search?q=module+system+top-qualification
https://www.google.ch/search?q=define+hygienic+module+system

> - yet if I am forced to resort to idioms, I want to get most out of it :)

This was the example given in that post:

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

FWIW:

---
use mypkg::mysubpkg::mod1 as myuse;
use mypkg::mysubpkg::mod2 as myuse;
---

error: a module named `myuse` has already been imported in this module [E0252]
use mypkg::mysubpkg::mod2 as myuse;
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You have to resort to the following idiom:

mod myuse{
    pub use mypkg::mysubpkg::mod1::*;
    pub use mypkg::mysubpkg::mod2::*;
}

Now, note: if there is any identifier `foo' which is exported by both `mod1' and `mod2', then the Rust compiler will error out eagerly here, even if `myuse::foo' never occurs in the code.

How is this superior?

AFAICS, the only other major semantic difference which would make Rust's system vastly superior is given by the situation that DMD comically thinks private symbols have a reason to cause conflicts in other modules. Was this your "hygiene" point?

On Thursday, 13 August 2015 at 16:22:04 UTC, Dicebot wrote:
> 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

Thank God, D does it the "not good" way. But I guess that is subjective thing. Some people like it one way, others like it the other way.

I humbly belive D's way is good. Compiler should issue a warning when conflicts arrive. This is not Python for Haven's sake!

On 08/14/2015 05:55 PM, Dejan Lekic wrote:
> On Thursday, 13 August 2015 at 16:22:04 UTC, Dicebot wrote:
>> 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
>
> Thank God, D does it the "not good" way. But I guess that is subjective
> thing. Some people like it one way, others like it the other way.
> ...

Rust supports both. D supports both. I still fail to see how one language can be seen to handle it in a "good" way and the other in a "not good" way, beyond trivial syntactic considerations and compiler bugs.

Is it a language-cultural issue?

> I humbly belive D's way is good. Compiler should issue a warning when
> conflicts arrive.

But only then, please. :o)

Ok, let's stop for a minute and make sure we are on the same thread here. Because you seem to argue something I have never said or at least intended to say.

So, my basic statements:

1. I don't like default D import semantics but I am not proposing to change it
2. I like Rust default import semantics (requiring module name) more than default D one. It is possible to emulate it by turning every single import into aliased import.
3. Idiom proposed in the first post is based on similar reasoning as Rust behavior but is different in functionality (one I find even more practical personally).
4. Both feel more practical to me than default D behavior and both require custom idioms/conventions in D

Does that make sense?

On 08/14/2015 08:57 PM, Dicebot wrote:
> Ok, let's stop for a minute and make sure we are on the same thread
> here. Because you seem to argue something I have never said or at least
> intended to say.
> ...

OK. This is my view: The sub-thread was started with the claim that the module system is "completely broken" in a particular way. You gave Rust's system as an alternative, but it is (basically) the same thing with slightly different syntax.

> So, my basic statements:
>
> 1. I don't like default D import semantics but I am not proposing to
> change it
> 2. I like Rust default import semantics (requiring module name) more
> than default D one. It is possible to emulate it by turning every single
> import into aliased import.
> 3. Idiom proposed in the first post is based on similar reasoning as
> Rust behavior but is different in functionality (one I find even more
> practical personally).
> 4. Both feel more practical to me than default D behavior and both
> require custom idioms/conventions in D
>
> Does that make sense?

Not really. It is up to the programmer which of the idioms to use by default, and all options exist in both languages.

It's not that important, I guess.

On Friday, 14 August 2015 at 20:12:43 UTC, Timon Gehr wrote:
> On 08/14/2015 08:57 PM, Dicebot wrote:
>> Ok, let's stop for a minute and make sure we are on the same thread
>> here. Because you seem to argue something I have never said or at least
>> intended to say.
>> ...
>
> OK. This is my view: The sub-thread was started with the claim that the module system is "completely broken" in a particular way. You gave Rust's system as an alternative, but it is (basically) the same thing with slightly different syntax.

I called it broken because it makes impossible to add new symbols to the library without possibly breaking user code. Same scenario in Rust is much less likely - comparing default import semantics, of course. And idioms don't matter because only very few use them, thus I only consider default import behaviour when making such statement.

Still disagree?

>> Does that make sense?
>
> Not really. It is up to the programmer which of the idioms to use by default, and all options exist in both languages.
>
> It's not that important, I guess.

Won't try to convince anyone about good style and stuff. All I need is some confirmation that presented nested import semantics will stay :( Will try poking Walter personally.

On 08/15/2015 06:15 PM, Dicebot wrote:
> On Friday, 14 August 2015 at 20:12:43 UTC, Timon Gehr wrote:
>> On 08/14/2015 08:57 PM, Dicebot wrote:
>>> Ok, let's stop for a minute and make sure we are on the same thread
>>> here. Because you seem to argue something I have never said or at least
>>> intended to say.
>>> ...
>>
>> OK. This is my view: The sub-thread was started with the claim that
>> the module system is "completely broken" in a particular way. You gave
>> Rust's system as an alternative, but it is (basically) the same thing
>> with slightly different syntax.
>
> I called it broken because it makes impossible to add new symbols to the
> library without possibly breaking user code. Same scenario in Rust is
> much less likely - comparing default import semantics, of course. And
> idioms don't matter because only very few use them, thus I only consider
> default import behaviour when making such statement.
>
> Still disagree?
> ...

Sure, but I think the disagreement is on what it /means/ for a module system to be broken, hence it is not actually important. Thanks!

>>> Does that make sense?
>>
>> Not really. It is up to the programmer which of the idioms to use by
>> default, and all options exist in both languages.
>>
>> It's not that important, I guess.
>
> Won't try to convince anyone about good style and stuff. All I need is
> some confirmation that presented nested import semantics will stay :(
> Will try poking Walter personally.

Ok. Still "yes" is the only answer that makes any sense, and breaking legitimate D code is not among Walter's priorities. :-)

On 8/13/2015 6:12 AM, Dicebot wrote:
> Right now this works:
>
> ``D
> struct Std
> {
>    public import std.stdio;
> }
>
> void main()
> {
>    Std.writeln("Nice!");
> }
> ```
>
> I want to use it as an import hygiene idiom but not entirely sure if this
> behavior can be relied upon (or it is just a side effect of imports being
> implemented as aliases currently).

It has nothing to do with aliases.

Imports work the same way as template mixins do. They share the same implementation code.

Since the import is qualified with 'public', I see no reason to change this behavior.