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/

Reply via email to