Beta 2.079.0

[Martin Nowak]

On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak wrote:
Regarding the sheer amount of discussion I want to note that this 
was primarily seen as a regularization of the existing grammar.

import mod1, mod2 : sym1, sym2;

Certainly other languages have decided on a clearer syntax for 
selective imports, but that's what was chosen for D a long time 
ago.
Learning D you'll find that the selective import syntax is 
ambiguous in your first week, so I've stopped being annoyed by 
that some 5 years ago.

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.

----

Unfortunately it's a bit hard to find arguments in the discussion 
below, would have been cool if there were a few well argumented 
comments instead dozens of +1s.

- this grammar is ambiguous

   It has always been in various ways and that's annoying to learn 
when you first deal with D. Personally I find it even more 
annoying that you can mix imports and selective imports, but only 
in a very specific exception.

- why not X instead

   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.

- 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).
   For projects and libraries it hardly matters, just adopt to the 
style-guide and existing code.
   Apparently I didn't use it a single time here 
https://github.com/MartinNowak/io, but all the time here 
https://github.com/MartinNowak/AoC17.
   Cannot say that it even took an active decision. It's just a 
very different mode if you want to quickly script sth. or if you 
set aside time to write a well-documented library.

- use std.experimental.scripting

   Indeed an alternative with a similar goal, reducing the amount 
of typing/noise for hacking. Importing all phobos modules will 
lead to a couple of symbol conflicts (e.g. write), and it still 
increases compile times and binary sizes noteably (though compile 
time is a lot better than it used to be).
   Not sure that this approach will pan out in the long-term, but 
a well curated package of the most used functions would indeed be 
helpful as of today.

- why hasn't this been a DIP

   Because it looked primarily like a minor grammar rectification 
that doesn't break anything and is entirely optional.
   Also DIPs are a crucial process for our language, and it seems 
problematic to clog it with trivialities.

----

On the other side please note that:

- you don't have to use it
- it will unlikely land in phobos' style-guide
- it's useful for talks, posts, code puzzles or on a repl where 
code is size constrained
- there is no ambiguity or chance for bugs
- practical examples of this usage are hardly confusing

   import std.stdio : writeln, std.algorithm : find;

- what's usually of relevance is the call-site not what you import
- there is syntax highlighting
- 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)
- remember that some people use `import mod1, mod2, mod3, mod4;` 
at least sometimes while others
   prefer each import on it's own line
- imports are mostly for tooling, less for humans
   - many java editors collapse the import manifest at the top
   - a lot of languages have an import std.* operator or 
auto-imports
   - you might want to automate import declarations at some point

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.

-Martin