On Friday, 23 February 2018 at 17:47:08 UTC, Kagamin wrote:
>> auto result = foo(), bar();
> Doesn't look like it works.
>
> ---
> int f(int a){ return a; }
> int main()
> {
>     int a=f(0),f(1); //doesn't compile
>     return 0;
> }
> ---
> int f(int a){ return a; }
> int main()
> {
>     int a;
>     a=f(0),f(1);
>     assert(a==1); //fails
>     return 0;
> }
> ---
> https://run.dlang.io/is/IgArs0

Yeah that should result in an error: https://issues.dlang.org/show_bug.cgi?id=18508

On Monday, 19 February 2018 at 20:17:05 UTC, Andre Pany wrote:

You also need to install VC++ 2015 redistributable to run lld-link.exe. Let's see if we can lift that requirement until the release.
[18509 – [Beta 2.079] lld-link.exe needs msvcp140.dll](https://issues.dlang.org/show_bug.cgi?id=18509)

On Friday, 23 February 2018 at 13:42:45 UTC, psychoticRabbit wrote:
> On Friday, 23 February 2018 at 12:06:23 UTC, Patrick Schluter wrote:
>> Absolutely. D scripting is the trojan horse that enables introduction of it in hostile environment. Runnable compiled source code is nice.
>
> scripting languages is reinventing computer science.. only really badly.

No, scripting languages is about getting shit done...

On Friday, 23 February 2018 at 18:13:01 UTC, Martin Nowak wrote:
> On Monday, 19 February 2018 at 20:17:05 UTC, Andre Pany wrote:
>
> You also need to install VC++ 2015 redistributable to run lld-link.exe.

The x86 one btw.

Also [18510 – [Beta 2.079] lld-link.exe fails to open obj file in subpath](https://issues.dlang.org/show_bug.cgi?id=18510) so it doesn't work with dub and likely fails for more complex applications.

On Friday, 23 February 2018 at 19:06:42 UTC, Martin Nowak wrote:
> On Friday, 23 February 2018 at 18:13:01 UTC, Martin Nowak wrote:
>> On Monday, 19 February 2018 at 20:17:05 UTC, Andre Pany wrote:
>>
>> You also need to install VC++ 2015 redistributable to run lld-link.exe.
>
> The x86 one btw.
>
> Also [18510 – [Beta 2.079] lld-link.exe fails to open obj file in subpath](https://issues.dlang.org/show_bug.cgi?id=18510) so it doesn't work with dub and likely fails for more complex applications.

Thanks a lot for the info. I will give it a try.

Kind regards
Andre

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

On Friday, 23 February 2018 at 10:48:10 UTC, psychoticRabbit wrote:
> On Friday, 23 February 2018 at 09:48:33 UTC, Norm wrote:
>>
>> This import feature and surrounding discussion I couldn't care less about ...
>
> I actually spend far more time reading large chunks of code, than writing code, and I certainly do NOT want to spend extra time deciphering imports, due to an unpopular and confusing syntax change.
>
> If I were mainly writing 'scripts', then I too would probably not care less ;-)
>
> If D just wants to become a compiled scripting language...good luck to it.
>
> I'll go find a proper progamming langauge long before that happens.

Well, D is already a compiled scripting language :)

It is also a language used for BSD and Linux kernel drivers, applications, backend servers et. al. So you can have your cake and eat it too.

Cheers,
Norm

On Friday, 23 February 2018 at 18:13:51 UTC, Patrick Schluter wrote:
> On Friday, 23 February 2018 at 13:42:45 UTC, psychoticRabbit wrote:
>> On Friday, 23 February 2018 at 12:06:23 UTC, Patrick Schluter wrote:
>>> Absolutely. D scripting is the trojan horse that enables introduction of it in hostile environment. Runnable compiled source code is nice.
>>
>> scripting languages is reinventing computer science.. only really badly.
>
> No, scripting languages is about getting shit done...

that's exactly the problem.

we're all to focused on getting 'shit' done ;-)

On Friday, 23 February 2018 at 23:46:02 UTC, Norm wrote:
> Well, D is already a compiled scripting language :)

technically (and otherwise) that is not correct...thank god!

lets keep it that way.

On Friday, 23 February 2018 at 16:03:56 UTC, Aurélien Plazzotta wrote:
>
> Perhaps, we could use Backus-Naur notation, as it is already widely known into formal documents all over the globe, like the following:
>
> import std.stdio, std.whatever{this, that}, std.somethingelse, std.grr{wtf};
>
> That is with curly brackets instead of square brackets like you suggest :)

Yeah...again.. I'd prefer to not to have to think differently about syntax, just for writing imports. That's why I'd prefer to just think of them as arrays using D's array like syntax.

import std.stdio [writeln, write = cwrite, writefln], std.whatever;

I'm not sufficiently motivated to do anything here anyway, as I don't believe a case for change can really be justified - cause how many imports can you realistically include on a single line anyway?

The current way is just fine, and provides really good clarity for what's going on.

But I would (and am) very, very motivated to oppose introduction of an obscure, confusing, or foreign syntax.

The real motivator for the change, as i see it, seemed to be related to thinking that the imports section was not really for human consumption - which it not true at all. The second motivate seemed to be related to saving a few keystrokes or line space. Again, human consumption should take priority here in my view.

Anyway, the point is moot at this point - since the change is being reversed and nobody seems motivated to push it again. Which is just fine with me ;-)