On Friday, 14 February 2020 at 21:35:10 UTC, Walter Bright wrote:
 On 2/13/2020 9:53 PM, Mathias Lang wrote:
>> This fits your own definition of "shuffling things around to no benefit".
>
> Significantly simplifying the language is not shuffling.

Simplifying something isnt objectively better. Anyways, this is simplifying the language (by an insignificant margin) but greatly complicating large code that used this feature, that was being simplified as a result of the feature.

On 2/14/2020 7:59 PM, jxel wrote:
> ... greatly complicating ...

I know that n.g. discussions have a tendency to defend to the death a single stone and forget the quarry, but come on.

On Saturday, 15 February 2020 at 04:50:31 UTC, Walter Bright wrote:
> On 2/14/2020 7:59 PM, jxel wrote:
>> ... greatly complicating ...
>
> I know that n.g. discussions have a tendency to defend to the death a single stone and forget the quarry, but come on.

If you have a large amount of code with nesting, yes. This is a big step backwards. The justification is flimsy and this will break code. There's bigger fish to fry that will have a more meaningful impact and won't break even more code.

On 2020-02-14 15:46, Steven Schveighoffer wrote:

> Foo f = Foo(ber: (a: 42, b: 84)); // only valid for struct 

(a: 42, b: 84) looks like a tuple with named elements to me.

-- 
/Jacob Carlborg

On Saturday, 15 February 2020 at 08:59:44 UTC, Jacob Carlborg wrote:
> On 2020-02-14 15:46, Steven Schveighoffer wrote:
>
>> Foo f = Foo(ber: (a: 42, b: 84)); // only valid for struct
>
> (a: 42, b: 84) looks like a tuple with named elements to me.

Exactly, a tuple-record hybrid. With Timon Gehr's tuple proposal + optionally named tuple elements + named parameters proposal, various forms of struct ctor invocation may become possible: Foo f = ((42, 84),) or Foo f = (ber: (a: 42, b: 84)) or auto f = Foo(ber: Bar(b: 84, a: 42)), etc.

On Thursday, 13 February 2020 at 08:52:41 UTC, Paolo Invernizzi wrote:
> Anyway, the DIP is fine, I've always hated brace-style struct initializers, let's kill them with fire.

13 years of D and I didn't know brace-style struct initializers even existed... Sounds error prone.

On 2/14/20 6:44 PM, Walter Bright wrote:
> On 2/14/2020 2:11 PM, Steven Schveighoffer wrote:
>> ... // some many lines later
> 
> It can be done inline with lambdas, like dmd itself does:
> 
>    https://github.com/dlang/dmd/blob/master/src/dmd/backend/oper.d#L387
> 
> and the lambdas can be arbitrarily complex. I wrote those bits to replace the optabgen.d program.

Not sure what this is supposed to mean. I hope not:

auto moves = Moves!double(items: [(){return Vector2d!double(x: 1, y: 0); }(), ...])

-Steve

On 2/14/20 11:50 PM, Walter Bright wrote:
> On 2/14/2020 7:59 PM, jxel wrote:
>> ... greatly complicating ...
> 
> I know that n.g. discussions have a tendency to defend to the death a single stone and forget the quarry, but come on.

From the perspective of the user, the complications in the compiler or library are of zero significance. They care about what they have to write to get what they want, and how that code performs.

In other words, they are not even in the quarry, but in the processing plant (or whatever you call the place the stones go after they are harvested).

-Steve

On 16/02/2020 3:39 AM, Steven Schveighoffer wrote:
> On 2/14/20 11:50 PM, Walter Bright wrote:
>> On 2/14/2020 7:59 PM, jxel wrote:
>>> ... greatly complicating ...
>>
>> I know that n.g. discussions have a tendency to defend to the death a single stone and forget the quarry, but come on.
> 
>  From the perspective of the user, the complications in the compiler or library are of zero significance. They care about what they have to write to get what they want, and how that code performs.
> 
> In other words, they are not even in the quarry, but in the processing plant (or whatever you call the place the stones go after they are harvested).
> 
> -Steve

Except when the compiler ICE's out, they certainly care then.

Compiler errors are to be expected when you don't have a full time team working on a compilers internal.

From Walter's perspective it makes sense to want to limit the surface area of potential new bugs when you don't have the support to back you up.

You can talk about quarries and processing plants but either the customer gets the exact product they want in the time that they have paid for or they don't.

If we genuinely cared about the user, we should be doing HCI studies and doing formal proving of language constructs. But we don't. We cut corners because we have no choice to do so as it is too costly.

The best way to resolve this situation from what I've seen is to heed off as many different perspectives in the DIP and have the DIP author chime in to expand on the discussion as soon as reasonably possible. This is something Walter could improve on.

On 2/15/20 10:03 AM, rikki cattermole wrote:
> On 16/02/2020 3:39 AM, Steven Schveighoffer wrote:
>> On 2/14/20 11:50 PM, Walter Bright wrote:
>>> On 2/14/2020 7:59 PM, jxel wrote:
>>>> ... greatly complicating ...
>>>
>>> I know that n.g. discussions have a tendency to defend to the death a single stone and forget the quarry, but come on.
>>
>>  From the perspective of the user, the complications in the compiler or library are of zero significance. They care about what they have to write to get what they want, and how that code performs.
>>
>> In other words, they are not even in the quarry, but in the processing plant (or whatever you call the place the stones go after they are harvested).
>>
> 
> Except when the compiler ICE's out, they certainly care then.

Sure, but it doesn't. brace-initializers have been in the language from the beginning and they are a proven feature.

> Compiler errors are to be expected when you don't have a full time team working on a compilers internal.

In general having the compiler simpler means an easier-to-maintain compiler. But simplifying the language to remove already working and proven features isn't progress. Unless you give them a new feature that replaces it (which could happen, if we wanted it to).

> You can talk about quarries and processing plants but either the customer gets the exact product they want in the time that they have paid for or they don't.

I think we are saying the same thing. The user only cares if it works, not how hard it was to implement. If it works as expected, and is bug free (it currently is), then to the user, removing it means losing the feature. It doesn't mean a less buggy compiler.

It the brace initializers were riddled with bugs or design issues, then I can see a benefit for users. This isn't the case. Removing features has to have a better story than simplification of language.

We could simplify foreach and for loops into just while loops. The language would be simpler and less surface area for mistakes. But the users would be not very happy about such a change.

-Steve