On Friday, February 23, 2018 02:20:41 psychotyicRabbit via Digitalmars-d- announce wrote:
> 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):
>
> e.g.
>
> import std.stdio, std.whatever[this, that], std.somethingelse, std.grr[wtf];
>
> I actually really like that syntax. It's really efficient for my brain to process.

We deprecate stuff when we need to, but every time we deprecate something, it breaks code (even if it's not immediate breakage), so the benefits that come from a deprecation need to be worth the breakage that it causes. Every D program on the planet which isn't completely trivial uses imports, and many of them use selective imports. So, you're talking about breaking a large percentage of the existing programs for a syntax change. That's not likely to go over well. Large breakage like that can be acceptable when it clearly fixes bugs but not just for aesthetics.

- Jonathan M Davis

On Friday, 23 February 2018 at 01:53:45 UTC, Martin Nowak wrote:
> On Friday, 23 February 2018 at 01:16:24 UTC, Jonathan M Davis wrote:
>> I can sympathize with wanting to avoid bikeshedding, but almost no one who has posted thinks that this is a good idea.
>
> This was meant for the discussion of a new syntax for selective imports like `import mod : { sym1, sym2 }` which seems like too much churn to be worthwhile.

import mod : { sym1, sym2 }

thats not nice syntax - for these reasons:

first, why is the : needed? {} is enough to enscapsulate the intention.

second, why are using {} instead of []

[] would allow me to think of selective importing, as though I were importing an array of selections.

e.g:
import std.stdio, std.whatever[this, that], std.somethingelse, std.grr[wtf];

so using [] would be consistent with using array like syntax elsewhere in D, and would require no additional effort to think about.

On Friday, 23 February 2018 at 02:31:34 UTC, Jonathan M Davis wrote:
>
> We deprecate stuff when we need to, but every time we deprecate something, it breaks code (even if it's not immediate breakage), so the benefits that come from a deprecation need to be worth the breakage that it causes. Every D program on the planet which isn't completely trivial uses imports, and many of them use selective imports. So, you're talking about breaking a large percentage of the existing programs for a syntax change. That's not likely to go over well. Large breakage like that can be acceptable when it clearly fixes bugs but not just for aesthetics.
>
> - Jonathan M Davis

yeah I do agree. I'd prefer no change. I don't really see the need.

On the otherhand, if change is coming, lets make it a sensible change ;-)

On Friday, 23 February 2018 at 02:31:34 UTC, Jonathan M Davis wrote:
> We deprecate stuff when we need to, but every time we deprecate something, it breaks code (even if it's not immediate breakage), so the benefits that come from a deprecation need to be worth the breakage that it causes. Every D program on the planet which isn't completely trivial uses imports, and many of them use selective imports. So, you're talking about breaking a large percentage of the existing programs for a syntax change. That's not likely to go over well. Large breakage like that can be acceptable when it clearly fixes bugs but not just for aesthetics.
>
> - Jonathan M Davis

oh..and really, there should be no need to deprecate anything here anyway.

surely D can handle the current way of doing imports (not including that rubbish in beta), and also a new way for those that want to use it, or those that want put stuff on a single line.

import std.stdio, std.whatever[this, that], std.somethingelse, std.grr[wtf];

This new syntax that I'm proposing (after reviewing discussions here) seems like a sensible change. It's very easy for the brain to chunk into components (unlike that rubbish in beta), and it introduces thinking about 'selective imports' as just being an array of selections, using the same array like syntax used elsewhere in D.

I would be interested to see what controversy would result from this new proposal, compared to the current change in beta.

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

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

I'm glad common sense seems to be winning ;-)

This is a good case for 'review of process' I think.

The original request for change was very flawed, in that it presupposed "importing as an expenditure that should be minimized.".

I think that is highly debatable, and more people should have had the opportunity to comment on that.

Second, none of the proposed syntax options was sufficiently clear, for the brain to chunk into its components. This is a serious issue and should be of greatest priority when introducing changes to syntax (no matter how small the change).

Changes to syntax need to be tested widely, for precisely this reason. You can do whole Phd's on this topic.

Third, making D more and more like a quick scripting/hacking language (by removing or hiding so called 'noise', is not a good idea in my opinion. That too seemed to be a motivator for at some aspect of the change.

On 2018-02-19 11:49, Martin Nowak wrote:

> Glad to announce the first beta for the 2.079.0 release, ♥ to the 77
> contributors for this release.

The following is a regression that breaks DWT:

extern (C) void foo(int) { }
extern (C) void foo(double) { }

The above used to compile but now results in:

main.d(2): Error: function main.foo(double) cannot be overloaded with another extern(C) function at main.d(1)

Was reported before the beta was released [1].

[1] https://issues.dlang.org/show_bug.cgi?id=18385

-- 
/Jacob Carlborg

[snip]
On Friday, 23 February 2018 at 04:06:23 UTC, psychoticRabbit wrote:
>
> Third, making D more and more like a quick scripting/hacking language (by removing or hiding so called 'noise', is not a good idea in my opinion. That too seemed to be a motivator for at some aspect of the change.

This import feature and surrounding discussion I couldn't care less about but I have to chime in and disagree with this particular point. Ability to quickly script in D was a big selling point for D at my workplace, I'd say *the* feature that got uninterested developers listening and trying the language. Being able to replace their Python scripts with a fast native language that is also used for application and drivers development was a winning formula.

Cheers,
Norm

On Friday, 23 February 2018 at 09:18:33 UTC, Jacob Carlborg wrote:
> On 2018-02-19 11:49, Martin Nowak wrote:
>
>> Glad to announce the first beta for the 2.079.0 release, ♥ to the 77
>> contributors for this release.
>
> The following is a regression that breaks DWT:
>
> extern (C) void foo(int) { }
> extern (C) void foo(double) { }
>
> The above used to compile but now results in:
>
> main.d(2): Error: function main.foo(double) cannot be overloaded with another extern(C) function at main.d(1)
>
> Was reported before the beta was released [1].
>
> [1] https://issues.dlang.org/show_bug.cgi?id=18385

Overloaded `extern(C)` functions has also been reported as a bug at https://issues.dlang.org/show_bug.cgi?id=15217

On Friday, February 23, 2018 10:08:58 Mike Franklin via Digitalmars-d- announce wrote:
> On Friday, 23 February 2018 at 09:18:33 UTC, Jacob Carlborg wrote:
> > On 2018-02-19 11:49, Martin Nowak wrote:
> >> Glad to announce the first beta for the 2.079.0 release, ♥ to
> >> the 77
> >> contributors for this release.
> >
> > The following is a regression that breaks DWT:
> >
> > extern (C) void foo(int) { }
> > extern (C) void foo(double) { }
> >
> > The above used to compile but now results in:
> >
> > main.d(2): Error: function main.foo(double) cannot be
> > overloaded with another extern(C) function at main.d(1)
> >
> > Was reported before the beta was released [1].
> >
> > [1] https://issues.dlang.org/show_bug.cgi?id=18385
>
> Overloaded `extern(C)` functions has also been reported as a bug at https://issues.dlang.org/show_bug.cgi?id=15217

Yeah, while I sympathize if this broken DWT, I don't see how this can actually work and have no idea how it every worked. You can't overload functions in C. That's why C++ and D name mangling adds type stuff to the name, but extern(C) tells the compiler to use C name mangling, so you lose that.

- Jonathan M Davis