On 2/23/18 8:13 AM, jmh530 wrote:
> On Friday, 23 February 2018 at 11:57:05 UTC, Martin Nowak wrote:
>>
>> 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;
>>
> 
> What if you have something like
> import std.stdio, std.conv : to, parse;
> and there is a module at the top-level named parse?

Then you have to import it on a separate line, or import it first.

It's why I put one import per line. It's second nature to me, I don't even think of putting imports on the same line.

But I think the better solution to this is instead making imports that collect other imports together. For instance, I rarely import std.algorithm.X, I usually use std.algorithm, even for selective imports. That seems more natural, and I don't have to look up which submodule it's in.

-Steve

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.

On Friday, 23 February 2018 at 03:26:11 UTC, Seb wrote:
> On Friday, 23 February 2018 at 03:20:22 UTC, psychoticRabbit wrote:
>> compared to the current change in beta.
>
> FWIW the change is almost gone from the beta:
>
> https://github.com/dlang/dmd/pull/7939

Glad its *almost* gone. That change *almost* freaked me out.

On Friday, 23 February 2018 at 11:24:24 UTC, Jonathan M Davis wrote:
> On Friday, February 23, 2018 10:57:21 Martin Nowak via Digitalmars-d- announce wrote:
>> On Friday, 23 February 2018 at 10:48:10 UTC, psychoticRabbit
>>
>> wrote:
>> > If D just wants to become a compiled scripting language...good luck to it.
>>
>> That's certainly not the goal, but as with every tool people become very familiar with, it's used creatively for things other than initially intended.
>
> And D has a lot of the easy-of-use that folks like to attribute to scripting languages. Thanks to how hard stuff like string processing is in C/C++, there's frequently a perception that compiled languages are hard to use for a lot of stuff that folks like to use scripting languages for, whereas that really has nothing to do with whether the language is compiled or not. And D is much more on-par with scripting languages in that regard even though it's compiled. So, if someone uses a scripting language because of its use-of-use, D frequently works for those use cases just as well.
>
> There's no requirement that a compiled language be used for large programs or that it be hard to use for simple tasks. And D can be used for a whole range of program sizes and tasks. It's a solid general purpose language, and small scripts fit into that just as well as large applications do.
>
> - Jonathan M Davis

Very well said. Coming from the world of full stack (front-end and back-end),  D is the only language that provides me with all of C/C++ but in a more Javascript &  php way of easing development. Not only strings that are convenient to work with in D,  but its has generally been for me... convenience in dealing with data generally.

D is very well designed,  easy to understand, and can be a beast if you want. Its one language you need to learn to be useful in every domain. D is already enough as a scripting language. I can code in D as fast as in Javascript (Nodejs).

That's why my complaints have not been about the language but packages/library availability. D is my answer to one language for everything. Being general purpose language at it's core is a good thing. Best of both worlds.

std.range,  std.algorithms, std. string,  std.datetime solves 60% of all my needs. Useful stuff on Dub too. More will come with time.

On Friday, 23 February 2018 at 13:38:25 UTC, Steven Schveighoffer wrote:
> On 2/23/18 8:13 AM, jmh530 wrote:
>> 
>> What if you have something like
>> import std.stdio, std.conv : to, parse;
>> and there is a module at the top-level named parse?
>
> Then you have to import it on a separate line, or import it first.
>
> It's why I put one import per line. It's second nature to me, I don't even think of putting imports on the same line.
>
> But I think the better solution to this is instead making imports that collect other imports together. For instance, I rarely import std.algorithm.X, I usually use std.algorithm, even for selective imports. That seems more natural, and I don't have to look up which submodule it's in.
>
> -Steve

I'm all about one import per line and would have had no plans to use the syntax myself. Just trying to grok it.

On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote:
> The main use-case for craming multiple imports into a line is not libraries but scripting, examples, and maybe unit tests.

Those are cases when selective imports shouldn't be used. experimental.scripting was introduced to reduce import length to absolute minimum - 11 characters.

>   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).

Are renamed imports already lazy?
Tiny cli tool uses all its imports and doesn't benefit from laziness, only libraries do.

> - 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),

It's perfectly thinkable to use both `write` functions, and selective imports won't help you there, but renamed imports will.
Is it just me or people ignore existence of renamed imports? #RenamedImportsMatter

> and it still increases compile times and binary sizes noteably (though compile time is a lot better than it used to be).

Is it because of dead templates? As a temporary solution you can compile the code to a library, this way the linker will be able to skip unreferenced code.

> - 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.

Though the feature met skepticism from the start. Maybe voting can be used as a simplified DIP process, just needs more people.

> - it's useful for talks, posts, code puzzles or on a repl where code is size constrained

Non-selective always win in terms of size.

> - 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'd convert those to non-selective imports.
import std.algorithm.iteration, std.ascii, std.exception, std.format, std.meta, std.range, std.stdio, std.string;
(well, my editor has decent word wrapping)

On Friday, 23 February 2018 at 01:02:59 UTC, Martin Nowak wrote:
> Also https://en.wikipedia.org/wiki/Law_of_triviality, because this is certainly easier to grasp than https://github.com/dlang/druntime/pull/1282 (https://forum.dlang.org/post/mjsma6$196h$1@digitalmars.com)

If nobody opposes, commit it to experimental. What an AA can have beside getter and setter?

> https://github.com/dlang/druntime/pull/1282

github shows me just two changes in makefiles and nothing else, need to find where the code comes from.

On Friday, 23 February 2018 at 02:20:41 UTC, psychotyicRabbit wrote:
> On Friday, 23 February 2018 at 01:57:37 UTC, Martin Nowak wrote:
>> On Thursday, 22 February 2018 at 11:15:35 UTC, psychoticRabbit wrote:
>>> import std.rabbit [food, water], std.house, std.family [carer];
>>

>
> Also, D is pretty good a depracating stuff, so why not deprecate the current way of imports, and gradually move to something (that resolves issues):
>
> import std.stdio, std.whatever[this, that], std.somethingelse, std.grr[wtf];


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 :)

> 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