https://issues.dlang.org/show_bug.cgi?id=13855

--- Comment #1 from Martin Nowak <code@dawg.eu> ---
(In reply to Martin Nowak from comment #0)
> Much better signal/noise ratio.

Well not without syntax highlighting in Bugzilla, but if you copy that code into your editor you can see it.

--

https://issues.dlang.org/show_bug.cgi?id=13855

bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc

--- Comment #2 from bearophile_hugs@eml.cc ---
(In reply to Martin Nowak from comment #0)
> Couldn't we just allow this?
> 
>     import std.algorithm : copy, uniq, std.range : walkLength;
> 
> This is one of (very few) grammar warts that regularly annoy me, because I
> have to make it 2 lines
> 
>     import std.algorithm : copy, uniq;
>     import std.range : walkLength;

I prefer the version on two lines, because it's not easy for the eye to tell apart the ":" from the ",".

--

https://issues.dlang.org/show_bug.cgi?id=13855

--- Comment #3 from Martin Nowak <code@dawg.eu> ---
(In reply to bearophile_hugs from comment #2)
> (In reply to Martin Nowak from comment #0)
> > Couldn't we just allow this?
> > 
> >     import std.algorithm : copy, uniq, std.range : walkLength;
> > 
> > This is one of (very few) grammar warts that regularly annoy me, because I
> > have to make it 2 lines
> > 
> >     import std.algorithm : copy, uniq;
> >     import std.range : walkLength;
> 
> I prefer the version on two lines, because it's not easy for the eye to tell apart the ":" from the ",".

I do agree with you, although most module names have a dot in the middle, and
syntax highlighting could take of the rest.
But your argument actually misses the point. Imports are on the noise side of
S/N ratio when reading code. They can usually be skipped unless one actually
wants to know where a symbol comes from.
So in the above example, a seasoned programmer will already know what partion3,
schwarzSort, levenshteinDistance, and toUpper do and can focus on the complex
parts.

--

https://issues.dlang.org/show_bug.cgi?id=13855

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unspecified                 |D2

--

https://issues.dlang.org/show_bug.cgi?id=13855

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #4 from Walter Bright <bugzilla@digitalmars.com> ---
> Much better signal/noise ratio.

That's clearly a matter of opinion, as I find the multi-line import much more legible.

--

https://issues.dlang.org/show_bug.cgi?id=13855

--- Comment #5 from Martin Nowak <code@dawg.eu> ---
Well the point was that imports don't need to be that legible, because they
hardly are relevant during reading.
Java is famous for it's horrible import "manifests", many editors just fold
those blocks.

My main motivation is the following.
Whenever I have the following import (valid today)

import std.file, std.stdio : writeln;

and I need sth., say map, I can either prepend all of std.algorithm or add another selective import.

void foo(Range r)
{
    import std.file, std.stdio : writeln;
    import std.algorithm : map;

    writeln(r.map!readText);
}

And often import std.algorithm, std.file, std.stdio : writeln; is the much more
concise choice.
Also I'm usually sorting imports, which isn't possible when only the last one
supports selective imports.

--

https://issues.dlang.org/show_bug.cgi?id=13855

yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies@gmail.com

--- Comment #6 from yebblies <yebblies@gmail.com> ---
My opinion is that this is a language fix for a style issue, and would not pull its weight.

While we certainly do want to avoid the issue java has, we already do avoid most of that with the existing syntax.

For your 'signal/noise ratio' example, I consider the first example less noisy as the 'import' makes it clear what those lines are.

I personally only ever import from one module per line, and that seems to avoid the problems you're encountering.

--

https://issues.dlang.org/show_bug.cgi?id=13855

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #7 from Martin Nowak <code@dawg.eu> ---
Not that well received https://github.com/dlang/dmd/pull/6589.

--

https://issues.dlang.org/show_bug.cgi?id=13855

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--- Comment #8 from hsteoh@quickfur.ath.cx ---
In light of the recent move towards local imports vs. global imports, I'm starting to think that what we *really* want is for the compiler to *automate* imports for us.

It's analogous to the old days with (early versions of) C, where you have to declare all local variables at the top of the function.  C++ improved on this by allowing variable declarations closer to where they're actually used (I'm not sure if this is standard C, but recent implementations like gcc seem to have also adopted this in C code). This is like moving imports from module scope to local scope.

However, C++ (well, earlier versions of it) still suffered from having to type incredibly long type names, like:

------
std::vector<int>::iterator it = std::vector<int>::iterator::end;
------

D improved upon this by allowing the LHS type name to be elided where the type can be inferred by the compiler.  Most of the time, this is possible, so in modern idiomatic D code these days, using `auto x = ...` is commonplace and greatly improves legibility.

What if we had an analogous "import inference", where you don't need to spell out long complicated module names just to be able to use some symbol in some module std.abc.xyz?  Let the compiler figure it out for us.

This is still a raw initial idea, so it will need further refinement, but my thought is something along these lines:  suppose we introduced a "lazy import" construct:

------
auto myFunc(Args...)(Args args) {
    lazy import std.algorithm;
    return args.map!(x => x*2).filter!(x < 100);
}
------

The lazy import tells the compiler that if undefined symbols are encountered, it should look into std.algorithm to see if the symbol is defined there. If it is, implicitly import the module that it's defined in, and keep going. Otherwise emit an error message.

If there is any ambiguity that arises, e.g., both std.algorithm.foo.bar and std.algorithm.baz.bar exist, and `bar` is referred to, then also emit an error, and require disambiguation using the usual mechanisms (e.g., naming `foo.bar` or `baz.bar`).

If a recent proposal for `import std;` gets accepted, then we could even have:

------
lazy import std; // I'm lazy, just lookup all symbols in Phobos for me ... // use std.*.* to your heart's content
------

This could be placed either in module scope or in local scope, depending on just how lazy you are.  It kills all boilerplate and verbosity by reducing import statements to their bare minimum.

--

https://issues.dlang.org/show_bug.cgi?id=13855

--- Comment #9 from github-bugzilla@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/05854166c7a67f27b33f5a5670d8956e738b4881 fix Issue 13855 - multi-module selective import statements

- fixes the grammar inconsistency that import statements can import multiple
modules,
  but selective imports have to be in separate statements
- allow to add further `mod : sym1, sym2` blocks to import statement
- only allow non-ambiguous variations (requiring look-ahead of 2 tokens)

https://github.com/dlang/dmd/commit/00b6a4c9a752f1c1ffc21c988efc55b6d43c156d Merge pull request #6589 from MartinNowak/enh13855

fix Issue 13855 - multi-module selective import statements

--