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

Reply via email to