Beta 2.079.0

Steven Schveighoffer schveiguy at yahoo.com
Fri Feb 23 21:16:47 UTC 2018


On 2/23/18 6:57 AM, Martin Nowak wrote:
> On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
>> 17. Allow multiple selective imports from different modules in a 
>> single import statement
> 
> Let me hopefully conclude this discussion :).
> 
> We have an existing ambiguity in the language since at least dmd 1.0. 
> This is unfortunate but seems costly to remove and minor in impact 
> (after learning this behavior).
> 
>      import trees, fruits : apple, birds;
> 
> A newcomer to D could rightfully conclude that comma is a module 
> separator and the following is the correct syntax to import multiple 
> symbols.
> 
>      import std.stdio, std.conv : to, std.conv : parse;

Maybe I misunderstand the problem here,

birds must be a symbol under fruits in order for it to work (I tested 
it, and this is indeed the case).

Your post seems to suggest that the birds module is imported (as it has 
nothing to do with fruits). Is that what you meant?

In any case, I think we should not delay in discussing the merits of 
this, as Andrei seems to want this update, and we should have plenty of 
time now to discuss it before the 2.080 version.

> Embracing that existing ambiguity to support multi-module selective 
> imports wasn't well received, partly because it amplifies the ambiguity 
> and partly because multi-module imports are frowned upon.

I think the biggest problem really is that the problem it solves is so 
minor compared to the perceived ambiguity. As Andrei pointed out in the 
PR to revert, there really isn't a technical ambiguity. Only one 
possible interpretation makes sense. But to a human, it looks very 
ambiguous.

> On the plus side, we've understood that the actual wish for that syntax 
> arised from scripting and example contexts, which might be better 
> addressed by 
> https://dlang.org/changelog/2.079.0.html#std-experimental-scripting, 
> lazy import resolution by the compiler or a library, or automatic 
> imports (https://github.com/CyberShadow/AutoFix).

Yes, I think globbing together imports in one spot makes scripting and 
toy examples far easier to write. I'm reminded of my days at topcoder, 
when everyone had their "library" that just had all their proper imports 
and shorthand typedefs for things allowing them to code much faster 
during competitions.

> Furthermore there remain various ideas that would avoid the original 
> ambiguity. Whether such changes are worthwhile is up for discussion and 
> would benefit from someone taking the lead.

TBH, I'm somewhat opposed to mucking with import syntax. Seeing some of 
the examples of "all on one line" imports, it just looks so hard to 
parse through, I'd rather not worry about saving the keystrokes and line 
space.

> 
> I still think that local imports are nice for being explicit and 
> toolable but have the downside of being brittle.
> Something like bash style expansion could help to hit a sweet spot IMHO.
> 
>      import std.{algorithm : {find, findSplit}, stdio : writeln};
>      import std.experimental.allocator.building_blocks.{free_list, region};

For comparison:

import std.algorithm: find, findSplit;
import std.stdio : writeln;
import std.experimental.allocator.building_blocks.free_list;
import std.experimental.allocator.building_blocks.region;

I don't find the latter extra verbose (except std.experimental, but that 
should go away eventually). When you list all the modules in order, it's 
easy to visually parse and see the differences.

Perhaps a mechanism to specify submodules in a common large package may 
be useful.

> Given the effort required for a language change, it's seductive to 
> streamline seemingly small changes, but it certainly increases the risk 
> of design mistakes, thanks for appealing against this one.

And thanks for understanding the response and acting on it.

-Steve


More information about the Digitalmars-d-announce mailing list