fix Issue 13855 - multi-module selective import statements

[MartinNowak]

• allow to add further mod : sym1, sym2 blocks to import statement
• only allow non-ambiguous variations (requiring look-ahead of 2 tokens)

[dlang-bot]

Thanks for your pull request, @MartinNowak!

Bugzilla references

Auto-close	Bugzilla	Description
✓	13855	Allow multiple selective imports from different modules in a single import statement

[MartinNowak]

This will be somewhat of a bike-shedding issue, so please refrain from lengthy discussions and use the +1/-1 buttons, unless important arguments are missing.
Also look at the enhancement request 13855.

[mathias-lang-sociomantic]

Voted. Isn't that DIP material though ?

[WalterBright]

As mentioned on bugzilla, I find the result to be less legible, not more.

[MartinNowak]

Added a small argument, imports provide little information and ought to be concise IMHO. https://issues.dlang.org/show_bug.cgi?id=13855#c5

[MartinNowak]

If we cannot agree on this anyhow, would there be interest in a DIP for a bigger syntax change?
Sth. along the line of

import std.{algorithm : {map, find}, file : readText, stdio : writeln};

Again I'm finding myself spending lots of time typing and shoveling around noisy imports, so would like have a more concise syntax.

[MartinNowak]

Voted. Isn't that DIP material though ?

Do we really want to process every flyweight change through a DIP? IMO informal Bugzilla ERs are fine for small changes.

[MartinNowak]

Reopened given the current proliferation of selective imports.
dlang/phobos#5948
There are obviously two camps, Emacs and Vim users, D coders that use one import statement per line (java style e.g. https://github.com/dlang/phobos/blob/0ba08bb6530ce84709f141645e2f6f28ab551813/std/file.d#L86-L90) and D coders that cram all modules into a single import statement.
This PR fixes a small grammar irregularity, that prevents multiple select imports per import statement (e.g. https://github.com/dlang/phobos/blob/0ba08bb6530ce84709f141645e2f6f28ab551813/std/file.d#L98-L99).

[andralex]

there's no reason for this limitation to exist and it breaks the rule of least astonishment. no dip needed, please make part of the changelog

[wilzbach]

@andralex there's already a changelog included. We just need to update dlang.org

[wilzbach]

This still requires an update to the spec - can we please stop merging PRs that change the language, but haven't opened a PR to dlang.org?

[wilzbach]

This still requires an update to the spec - can we please stop merging PRs that change the language, but haven't opened a PR to dlang.org?

I gave it a try: dlang/dlang.org#2131

[timotheecour]

ignore my previous comment, we could use grep 'import.*std.range' **/*.d instead of egrep 'import(\s+)std.range' **/*.d

…

On Fri, Jan 26, 2018 at 6:28 PM, Timothee Cour ***@***.***> wrote: Something that wasn't raised before: my understanding is that this breaks grep-based search for imported modules. I doubt everyone uses dscanner for that. grep based search (or using ripgrep) is also much faster than dscanner for that (and doesn't require code to be 100% parsable). There are use cases for both. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6589 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACF9YAutqvSZjox_Y781TAs1oH4nQ-6sks5tOonZgaJpZM4MTPwm> .

[skl131313]

there's no reason for this limitation to exist and it breaks the rule of least astonishment. no dip needed, please make part of the changelog

@andralex
You can make the same argument for UDAs on function parameters if you want to go ahead and save the trouble of finishing the DIP for it ;)

#7576

Anyways this should have at least had a discussion for it. Even if the DIP process was going to be circumvented. Variable declarations can be done on the same line with one type as well. But there's a reason why I and many other programmers don't use it. This is a small change but an un-needed one. It doesn't add anything of value and as Walter said it makes it harder to read. Rule of least astonishment doesn't really apply here anyways, you are going to get a compiler error. One that has a very easy workaround. No broken code is going to end up being compiled and run. After encountering the compiler error once then the user will simply know that that style isn't supported and will continue on using the other styles available.

[timotheecour]

import mod : sym1, foo2; is ambiguous as others have noted in case foo2 is both a symbol in mod and a module.
how about instead using a different delimiter for modules? that would remove this ambiguity and ease other's concern that , as a module separator is hard (in some cases impossible, see my example) to distinguish from , as a symbol separator.

Example: use | (or maybe &) to delimit modules:

import mod : sym1, sym2 | foo2;
import mod : sym1, sym2 & foo2;

I don't care which symbol is used to separate modules so long it's not ,