On Monday, 23 July 2018 at 16:57:20 UTC, H. S. Teoh wrote:
> On Mon, Jul 23, 2018 at 04:26:42PM +0000, Seb via Digitalmars-d wrote:
>> tl;dr: the currently proposed syntax options are:
>> ---
>> struct S
>> {
>>     int a = 2, b = 4, c = 6;
>> }
>> void foo()
>> {
>>     bar(S({c: 10})); // Option 1
>>     bar(S(c: 10));   // Option 2
>>     bar(S{c: 10});   // Option 3
>> }
>> ---
>> 
>> So the struct-initialization DIP has been stalled for too long and I think it's time we finally get this story done.
>
> +1.
>
>
>> I personally prefer option 2, but this might be in conflict to named arguments which we hopefully see in the near future too.
>
> Yeah.
>
>
>> Hence, I'm leaning forward to proposing Option 1 as the recommended Option for the DIP (that's also what the PoC DMD PR implements). What's your take on this?
> [...]
>
> I don't like option 1 because it resembles anonymous function syntax and AA initialization syntax, but is actually neither.

Seeing as we already have

S s = { c : 10 };

I'd say it would be fairer to say it resembles anonymous function syntax and AA initialisation syntax, but mostly it resembles the existing struct initialisation syntax.

On Monday, 23 July 2018 at 18:02:04 UTC, Andre Pany wrote:
> I also prefer option 3. From a readability point of view it is the most pleasant one (my personal opinion). I also like it due to the already existing struct initialization syntax I am using a lot.

+1.

JohnB.

On Monday, 23 July 2018 at 17:32:23 UTC, aliak wrote:
> Can we just consider that named struct init syntax *is* a generated named constructor?
>
> If named arguments choose a different syntax then you have no conflict. If they go with the same (i.e. option 2) then you have seamless consistency.

+1. And hoping for the latter, seamless consistency.

On 2018-07-23 18:26, Seb wrote:
> tl;dr: the currently proposed syntax options are:
> 
> 
> ---
> struct S
> {
>      int a = 2, b = 4, c = 6;
> }
> void foo()
> {
>      bar(S({c: 10})); // Option 1
>      bar(S(c: 10));   // Option 2
>      bar(S{c: 10});   // Option 3
> }
> ---
> 
> So the struct-initialization DIP has been stalled for too long and I think it's time we finally get this story done.
> I personally prefer option 2, but this might be in conflict to named arguments which we hopefully see in the near future too. Hence, I'm leaning forward to proposing Option 1 as the recommended Option for the DIP (that's also what the PoC DMD PR implements). What's your take on this?
> 
> DIP: https://github.com/dlang/DIPs/pull/71
> Rendered view: https://github.com/wilzbach/DIPs/blob/struct-initialization/DIPs/DIP1xxx-sw.md 

Talking about future potential features, Option 1 could be in conflict with a tuple with named elements. Option 2 could be in conflict with named parameters, true, but named parameters could also have a different syntax, i.e. foo(a = 3, b = 4), this is what Scala is using.

-- 
/Jacob Carlborg

On 24/07/2018 7:11 AM, Jacob Carlborg wrote:
> On 2018-07-23 18:26, Seb wrote:
>> tl;dr: the currently proposed syntax options are:
>>
>>
>> ---
>> struct S
>> {
>>      int a = 2, b = 4, c = 6;
>> }
>> void foo()
>> {
>>      bar(S({c: 10})); // Option 1
>>      bar(S(c: 10));   // Option 2
>>      bar(S{c: 10});   // Option 3
>> }
>> ---
>>
>> So the struct-initialization DIP has been stalled for too long and I think it's time we finally get this story done.
>> I personally prefer option 2, but this might be in conflict to named arguments which we hopefully see in the near future too. Hence, I'm leaning forward to proposing Option 1 as the recommended Option for the DIP (that's also what the PoC DMD PR implements). What's your take on this?
>>
>> DIP: https://github.com/dlang/DIPs/pull/71
>> Rendered view: https://github.com/wilzbach/DIPs/blob/struct-initialization/DIPs/DIP1xxx-sw.md 
> 
> 
> Talking about future potential features, Option 1 could be in conflict with a tuple with named elements. Option 2 could be in conflict with named parameters, true, but named parameters could also have a different syntax, i.e. foo(a = 3, b = 4), this is what Scala is using.

We ugh can't use that syntax because of ambiguity to AssignExpression.

On 24/07/2018 6:43 AM, kinke wrote:
> On Monday, 23 July 2018 at 17:32:23 UTC, aliak wrote:
>> Can we just consider that named struct init syntax *is* a generated named constructor?
>>
>> If named arguments choose a different syntax then you have no conflict. If they go with the same (i.e. option 2) then you have seamless consistency.
> 
> +1. And hoping for the latter, seamless consistency.

Based upon my DIP that is in the queue for named arguments, it would be trivial for this DIP to make it so a named parameter constructor can override the default behavior and I think that this is the best way forward.

On Tuesday, 24 July 2018 at 03:59:53 UTC, rikki cattermole wrote:
> On 24/07/2018 6:43 AM, kinke wrote:
>> On Monday, 23 July 2018 at 17:32:23 UTC, aliak wrote:
>>> Can we just consider that named struct init syntax *is* a generated named constructor?
>>>
>>> If named arguments choose a different syntax then you have no conflict. If they go with the same (i.e. option 2) then you have seamless consistency.
>> 
>> +1. And hoping for the latter, seamless consistency.
>
> Based upon my DIP that is in the queue for named arguments, it would be trivial for this DIP to make it so a named parameter constructor can override the default behavior and I think that this is the best way forward.

Yes, it makes sense to review the "named arguments" DIP before this one, any link?

On 24/07/2018 7:23 PM, Daniel N wrote:
> On Tuesday, 24 July 2018 at 03:59:53 UTC, rikki cattermole wrote:
>> On 24/07/2018 6:43 AM, kinke wrote:
>>> On Monday, 23 July 2018 at 17:32:23 UTC, aliak wrote:
>>>> Can we just consider that named struct init syntax *is* a generated named constructor?
>>>>
>>>> If named arguments choose a different syntax then you have no conflict. If they go with the same (i.e. option 2) then you have seamless consistency.
>>>
>>> +1. And hoping for the latter, seamless consistency.
>>
>> Based upon my DIP that is in the queue for named arguments, it would be trivial for this DIP to make it so a named parameter constructor can override the default behavior and I think that this is the best way forward.
> 
> Yes, it makes sense to review the "named arguments" DIP before this one, any link?

Mine: https://github.com/dlang/DIPs/pull/126
Yshui's: https://github.com/dlang/DIPs/pull/123

Mine is a lot heavier-weight, and applies to templates parameters as well as functions. Where as Yshui's is very lightweight compared and only applies to functions.

Yshui's will occur first I think, but really we should review them together to decide what sort of approach is best.

On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote:
> What's your take on this?

Option 2 won't necessarily cause problems with named funcion arguments: The names of the constructor arguments and members are different anyway, at least usually, letting the compiler to infer the intended call by them.

But there might be some corner cases where this would not apply. Do you see any?

On Tuesday, 24 July 2018 at 10:48:40 UTC, Dukc wrote:
> On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote:
>> What's your take on this?
>
> Option 2 won't necessarily cause problems with named funcion arguments: The names of the constructor arguments and members are different anyway, at least usually, letting the compiler to infer the intended call by them.
>
> But there might be some corner cases where this would not apply. Do you see any?

That argument sounds quite dangerous to me, especially since my experience is on the contrary that constructor arguments are often named the same as the attribute they refer to. And what of mixed cases? I really wouldn't rely on anything like naming conventions for something like that.