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