On 08/13/2015 06:19 PM, Dicebot wrote:
> 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.
> ...

(It's about communicating clearly what the problem actually is. static imports are not inherently all-or-nothing.)

>>>
>>> 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;
>>
>> ?
>
> http://forum.dlang.org/post/szaaakmavraxatkrfpnx@forum.dlang.org
>

How is this relevant? Does Rust support it?

On 08/13/2015 06:22 PM, 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

static import std.stdio;
private alias stdio=std.stdio;

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

Well, that's better than requiring the full import path, but requiring _any_ module name is just plain annoying IMHO. If I were okay with that I wouldn't be doing stuff like

using namespace std;

in all of my .cpp files - and that's a really common thing to do.

- Jonathan M Davis

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 - yet if I am forced to resort to idioms, I want to get most out of it :)

On Thursday, 13 August 2015 at 16:37:00 UTC, Jonathan M Davis wrote:
> Well, that's better than requiring the full import path, but requiring _any_ module name is just plain annoying IMHO. If I were okay with that I wouldn't be doing stuff like
>
> using namespace std;
>
> in all of my .cpp files - and that's a really common thing to do.

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.

On Thursday, 13 August 2015 at 16:40:31 UTC, Dicebot wrote:
> On Thursday, 13 August 2015 at 16:37:00 UTC, Jonathan M Davis wrote:
>> Well, that's better than requiring the full import path, but requiring _any_ module name is just plain annoying IMHO. If I were okay with that I wouldn't be doing stuff like
>>
>> using namespace std;
>>
>> in all of my .cpp files - and that's a really common thing to do.
>
> 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.

Well, if name clashes become that high in a .cpp file, odds are that it's pulling in too much stuff.

> In my C++ projects such "using" abuse was normally banned.

I've never worked on a team that banned them. Every C++ project that I've ever worked on has used them heavily. It's common practice for every namespace that's being used in a .cpp file to having a corresponding using directive. On the rare cases where there's a collision, you then have to be more explicit, but I've never seen it be much of a problem - and definitely nowhere near enough of a problem to consider banning using directives. I'd _hate_ to be writing code that required being that explicit.

- Jonathan M Davis

On Thursday, 13 August 2015 at 17:06:18 UTC, Jonathan M Davis 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.
>
> Well, if name clashes become that high in a .cpp file, odds are that it's pulling in too much stuff.

My projects have been broken twice by adding new functions to druntime (and one was symbol added to object.di :)). Forgive me if I discard that argument as nonsense. If short names are allowed and project is big enough, clashes are simply inevitable. With D module system even medium size will do.

On Thursday, 13 August 2015 at 17:09:11 UTC, Dicebot wrote:
> On Thursday, 13 August 2015 at 17:06:18 UTC, Jonathan M Davis 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.
>>
>> Well, if name clashes become that high in a .cpp file, odds are that it's pulling in too much stuff.
>
> My projects have been broken twice by adding new functions to druntime (and one was symbol added to object.di :)). Forgive me if I discard that argument as nonsense. If short names are allowed and project is big enough, clashes are simply inevitable. With D module system even medium size will do.

Yes. Clashes are going to happen, especially if you're using short names heavily, but in C++, I've rarely had problems with it. D is potentially worse, because we don't have the equivalent separation of header and source files where it's only the source files that risk breakage. But still, I'd _much_ rather just deal with the occasional breakage than have to qualify everything.

- Jonathan M Davis

On 13-Aug-2015 20:17, Jonathan M Davis wrote:
> On Thursday, 13 August 2015 at 17:09:11 UTC, Dicebot wrote:
>> On Thursday, 13 August 2015 at 17:06:18 UTC, Jonathan M Davis 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.
>>>
>>> Well, if name clashes become that high in a .cpp file, odds are that
>>> it's pulling in too much stuff.
>>
>> My projects have been broken twice by adding new functions to druntime
>> (and one was symbol added to object.di :)). Forgive me if I discard
>> that argument as nonsense. If short names are allowed and project is
>> big enough, clashes are simply inevitable. With D module system even
>> medium size will do.
>
> Yes. Clashes are going to happen, especially if you're using short names
> heavily, but in C++, I've rarely had problems with it. D is potentially
> worse,

Because private symbols from imported modules *do* clash with public ones even though not accessible. THAT is the problem and header/source is not the reason of D doing worse here.

> because we don't have the equivalent separation of header and
> source files where it's only the source files that risk breakage. But
> still, I'd _much_ rather just deal with the occasional breakage than
> have to qualify everything.
>
> - Jonathan M Davis

-- 
Dmitry Olshansky

On Thursday, 13 August 2015 at 17:32:33 UTC, Dmitry Olshansky wrote:
> On 13-Aug-2015 20:17, Jonathan M Davis wrote:
>> On Thursday, 13 August 2015 at 17:09:11 UTC, Dicebot wrote:
>>> On Thursday, 13 August 2015 at 17:06:18 UTC, Jonathan M Davis 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.
>>>>
>>>> Well, if name clashes become that high in a .cpp file, odds are that
>>>> it's pulling in too much stuff.
>>>
>>> My projects have been broken twice by adding new functions to druntime
>>> (and one was symbol added to object.di :)). Forgive me if I discard
>>> that argument as nonsense. If short names are allowed and project is
>>> big enough, clashes are simply inevitable. With D module system even
>>> medium size will do.
>>
>> Yes. Clashes are going to happen, especially if you're using short names
>> heavily, but in C++, I've rarely had problems with it. D is potentially
>> worse,
>
> Because private symbols from imported modules *do* clash with public ones even though not accessible. THAT is the problem and header/source is not the reason of D doing worse here.

Oh. That makes the problem even worse, and it definitely needs to be fixed, but the fact that you're essentially forced to use fully qualified names in C++ for header files means that you're not going to run into name clashes in the public declarations - only in the function bodies in the .cpp file - whereas all of that is out in the open with .d files. So, the header/source separation does reduce the problem in C++, and even if we do fix the private symbol mess in D, D will still have more name clashing problems because it doesn't normally have that separation. But the private symbols affecting the public API is just plain embarrassing and definitely makes the problem _far_ worse.

- Jonathan M Davis