On Friday, 23 February 2018 at 00:41:58 UTC, psychoticRabbit wrote:
> On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote:
> Isn't that an argument?

Of course it is :).
I tried to list the arguments I found in the thread and replied to them, trying to lead a proper discussion.

>> - why not X instead
>
> Aren't alternative ideas welcome?

Yes they are. There was quite some chances to bring them up, maybe this needs more room for comments.

>>   Go for it and try to find a consensus. I don't think the issue is big enough to warrant a huge design and bikeshedding discussion.
> Some don't agree with you.

The price of discussing syntax, introducing an alternative (e.g. `import std.algorithm : { find, findSplit }`, and rewriting most D code is quite high.

> That's your opinion.

Yes, and it's an opinion that isn't reflected in the thread.

> You seem overly eager to save some typing, and the expense of comprehension.
> I don't get it. That's what bring programming languages into disrepute.

Reread what I wrote, you'll find that I make a distinction between scripting/hacking and programming.

> This doesn't seem that trivial based on the discussion.

It said seemed, so it might have been a wrong assessment.
But I still think we have quite heavy topics on our plate, @nogc, @safe, phobos quality, dub infrastructure and this still seems like a very tiny change to me.

Also https://en.wikipedia.org/wiki/Law_of_triviality, because this is certainly easier to grasp than https://github.com/dlang/druntime/pull/1282 (https://forum.dlang.org/post/mjsma6$196h$1@digitalmars.com) for which getting feedback is extremely tedious.

> I've learnt a lot from looking at imports used.

Interesting, you have a good example?

On Friday, February 23, 2018 00:05:59 Martin Nowak via Digitalmars-d- announce wrote:
> The main use-case for craming multiple imports into a line is not
> libraries but scripting, examples, and maybe unit tests.
> And indeed the changelog entry could have been a bit clearer and
> easier to grasp.

In that case, I would expect the programmer to just forgo selective imports. If they care that much about making the code short and/or writing the code quickly, then that makes a lot more sense than trying to cram as many selective imports as possible on a single line - particularly when the syntax for that is hard to read.

>    Go for it and try to find a consensus. I don't think the issue
> is big enough to warrant a huge design and bikeshedding
> discussion.

I can sympathize with wanting to avoid bikeshedding, but almost no one who has posted thinks that this is a good idea. Pretty much no one likes the syntax, and they either want a different syntax or don't want the feature at all. As such, it seems like a bad idea to add it. Not having total consensus is one thing. Having almost total consensus that it's a bad idea is another entirely.

> On the other side please note that:
>
> - you don't have to use it

This is always, always, always a terrible argument, because as much as you may not have to use a feature, you have to deal with code that other people write where they used the feature. And the syntax of this feature is hard to read, making it particularly bad when you encounter it if you never use it, since then you're that much less likely to be able to read it well.

- Jonathan M Davis

On Friday, 23 February 2018 at 01:02:59 UTC, Martin Nowak wrote:
>
>
> Interesting, you have a good example?

yeah..phobos.

I learn most about the various phobos libraries, and their usefulness, from looking at the various imports that phobos modules use.

If they just used import *; I'd have no idea what was going on.

On Friday, 23 February 2018 at 01:17:26 UTC, psychoticRabbit wrote:
> On Friday, 23 February 2018 at 01:02:59 UTC, Martin Nowak wrote:
>>
>>
>> Interesting, you have a good example?
>
> yeah..phobos.
>
> I learn most about the various phobos libraries, and their usefulness, from looking at the various imports that phobos modules use.
>
> If they just used import *; I'd have no idea what was going on.

and worse, if phobos used this new so-called 'optional' syntax...then I'd probably have switched to another language by now.

import pkg.mod1 : sym1, sym2, pkg.mod2 : sym1, sym2, pkg.mod3 : sym1;

I don't have the patience to decipher stuff like that.

On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote:
> - each imported module should be on it's own line
>
>   That's your opinion, my opinion is that importing 6 symbols from 6 different modules for a tiny cli tool sucks and bloats code example. So the alternative is to not use selective imports, but only those and static imports have a clear path to become lazy (https://issues.dlang.org/show_bug.cgi?id=13255).

This can be solved by adding a package.d to phobos. This doesn't need a language change that introduces more ambiguities for such a subjective matter as "I'm too lazy to write 5 more lines of code". 5 Lines of code is hardly bloat for a code example. Example code is better to follow best practices, or you get the whole `using namespace std` situation like you do with C++. The people that actually can comprehend won't be hindered by it, and everyone else it won't make a difference cause they have no understanding of what they are doing and just copy and paste the code.

On Friday, 23 February 2018 at 01:34:54 UTC, Rubn wrote:
> On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote:
>> - each imported module should be on it's own line
>>
>>   That's your opinion, my opinion is that importing 6 symbols from 6 different modules for a tiny cli tool sucks and bloats code example. So the alternative is to not use selective imports, but only those and static imports have a clear path to become lazy (https://issues.dlang.org/show_bug.cgi?id=13255).
>
> This can be solved by adding a package.d to phobos. This doesn't need a language change that introduces more ambiguities for such a subjective matter as "I'm too lazy to write 5 more lines of code". 5 Lines of code is hardly bloat for a code example. Example code is better to follow best practices, or you get the whole `using namespace std` situation like you do with C++. The people that actually can comprehend won't be hindered by it, and everyone else it won't make a difference cause they have no understanding of what they are doing and just copy and paste the code.

Yes, with 2.079 those who want, can do `import std.experimental.all` [1].
(It has been renamed from scripting to all since the prerelease changelog was created)

In later versions, it might be renamed to std/package.d, but we first want to assess whether there are potential problems except the potential collisions and potential decrease in "understandability". Anyhow, `experimental` is a good playground for such tests.

[1] https://dlang.org/changelog/2.079.0.html#std-experimental-scripting

On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote:
> - practical examples of this usage are hardly confusing
>
>   import std.stdio : writeln, std.algorithm : find;

I agree that that's not so bad, though it's more likely to look like this:

import std.stdio : writeln, stdin, stderr, stdout, std.algorithm : find, splitter, strip, std.string: chomp, splitLines;

Do you not see that people don't want to parse that in their head?

Here's what it looks like when some joker has a bunch of modules all in the same top-level folder:

import game : write, call, mean, engine : render, debug, blit, sprite : display, hide, move;

People don't want to read and figure out imports like that.

As I've said repeatedly, I like the feature and the problem it's trying to solve, just please give us some better syntax to make it easier to read.

> - we're currently proliferating selective imports which cause a lot of D code to become very brittle
>   (https://github.com/andralex/phobos/blob/cd3152c7bf4466e74b7fb9bd43d47e996caf5918/std/datetime/systime.d#L10076-L10083)

I don't know what's "brittle" about that, perhaps too verbose for your liking, but certainly clear.

> And last but not least, the simpler the topic the more opinions, so please refrain from "I don't like it, +1" and leave space for actual arguments.

While you and Walter are right that it's easy to bikeshed this relatively simple topic, please also consider that imports are something that people use all the time.  Every time I have to write some trivial test executable, I have to write some imports first, which can be as long or longer than writing the simple executed code itself.

This means every D dev has written some imports and doesn't want to seem them getting less clear to parse.  Maybe this is saliency bias, but it is worth weighing when changing a commonly-used feature:

https://thedecisionlab.com/bias/salience-bias/

On Friday, 23 February 2018 at 01:16:24 UTC, Jonathan M Davis wrote:
> I can sympathize with wanting to avoid bikeshedding, but almost no one who has posted thinks that this is a good idea.

This was meant for the discussion of a new syntax for selective imports like `import mod : { sym1, sym2 }` which seems like too much churn to be worthwhile.

On Thursday, 22 February 2018 at 11:15:35 UTC, psychoticRabbit wrote:
> import std.rabbit [food, water], std.house, std.family [carer];

What about the million lines of existing code using

import std.stdio : writeln, writefln;

On Friday, 23 February 2018 at 01:57:37 UTC, Martin Nowak wrote:
> On Thursday, 22 February 2018 at 11:15:35 UTC, psychoticRabbit wrote:
>> import std.rabbit [food, water], std.house, std.family [carer];
>
> What about the million lines of existing code using
>
> import std.stdio : writeln, writefln;

I actually like selective importing like that.

It tells me, the programmer was only interested in writeln and writefln from that module. It provides clarity of intention, as well as instructing new comers what modules contain, and where to find them.

Selective importing is a great tool for new comers to become familiar with the library - and lets be honest - it's all about the libraries these days - so the more one knows about them, the better they'll be utilised.

Also, D is pretty good a depracating stuff, so why not deprecate the current way of imports, and gradually move to something (that resolves issues):

e.g.

import std.stdio, std.whatever[this, that], std.somethingelse, std.grr[wtf];

I actually really like that syntax. It's really efficient for my brain to process.