This is the feedback thread for the first round of Community Review for DIP 1031, "Deprecate Brace-Style Struct Initializers":

https://github.com/dlang/DIPs/blob/c0c1c9f9665e0bc1db611f4e93e793d64451f763/DIPs/DIP1031.md

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits... in other words, business as usual.

However, if you have any specific feedback for how to improve the the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

The review period will end at 11:59 PM ET on February 27, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.

Please stay on topic here. I will delete posts that are completely off topic.

On Thursday, 13 February 2020 at 07:29:00 UTC, Mike Parker wrote:
>
> However, if you have any specific feedback for how to improve the the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post.

The Feedback thread is here:

https://forum.dlang.org/post/iywiuqqmevdghgbyrved@forum.dlang.org

On Thursday, 13 February 2020 at 07:29:00 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1031, "Deprecate Brace-Style Struct Initializers":

I'm in favor of a change. So there were two options

1. StructInitializers could have become StructLiterals, ie. a primary expression, i.e usable in all contexts, not only as initializer.

2. Kill them. By removing them you can now get rid of the special AST node for initializers. After the removal it will be either an array literal (so a primary), an AA literal (so a primary) or an expression, in other words always an expression. This option is also good to simplify the parser because struct literals could look like func literals without a full, arbitrarily long lookup.

Nobody wrote a proposal for 1. so let it be 2. End of story from my point of view.

On Thursday, 13 February 2020 at 07:30:49 UTC, Mike Parker wrote:
> On Thursday, 13 February 2020 at 07:29:00 UTC, Mike Parker wrote:
>>
>> However, if you have any specific feedback for how to improve the the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post.
>
> The Feedback thread is here:
>
> https://forum.dlang.org/post/iywiuqqmevdghgbyrved@forum.dlang.org

It makes me a little sad to read "With the adoption of named argument lists ..."

I'm wondering if discussing about the opportunity or not to add a feature worths the time, as every decision seems already taken 'a priori'.

Anyway, as it seems that named arguments is 'de-facto' approved, this DIP is the natural consequence, so that's fine.

On Thursday, 13 February 2020 at 08:22:19 UTC, Paolo Invernizzi wrote:

>
> It makes me a little sad to read "With the adoption of named argument lists ..."
>
> I'm wondering if discussing about the opportunity or not to add a feature worths the time, as every decision seems already taken 'a priori'.
>
> Anyway, as it seems that named arguments is 'de-facto' approved, this DIP is the natural consequence, so that's fine.

Please note the DIP also says:

"This DIP presumes the acceptance of DIP 1030: Named Arguments."

And in an effort to preempt comments like your, I explicitly left this note in the feedback thread:

"Please note that acceptance of this DIP is dependent upon acceptance of DIP 1030. If that DIP is rejected, this DIP will move into "Postponed" for an extended period to allow time for alternative named argument proposals."

I should have left it here, too :-)

Anyway, 1030 is likely to be accepted, but it isn't a given. Walter has pulled two of his DIPs in the past in response to community feedback, so please don't think any his DIPs is a rubber stamp. However, if it *is* accepted, then it saves time if we have both DIPs going through the review process close together. That's all this is.

On Thursday, 13 February 2020 at 08:46:31 UTC, Mike Parker wrote:
> On Thursday, 13 February 2020 at 08:22:19 UTC, Paolo Invernizzi wrote:
>
>> [...]
>
> Please note the DIP also says:
>
> "This DIP presumes the acceptance of DIP 1030: Named Arguments."
>
> And in an effort to preempt comments like your, I explicitly left this note in the feedback thread:
>
> "Please note that acceptance of this DIP is dependent upon acceptance of DIP 1030. If that DIP is rejected, this DIP will move into "Postponed" for an extended period to allow time for alternative named argument proposals."
>
> I should have left it here, too :-)
>
> Anyway, 1030 is likely to be accepted, but it isn't a given. Walter has pulled two of his DIPs in the past in response to community feedback, so please don't think any his DIPs is a rubber stamp. However, if it *is* accepted, then it saves time if we have both DIPs going through the review process close together. That's all this is.

Acknowledged,  sorry for that ... I need to remember to take the morning coffe before posting ... eheh

Anyway, the DIP is fine, I've always hated brace-style struct initializers, let's kill them with fire.

According to the DIP

This will be deprecated.

struct S { int a, b; }

S s = { 1, 2 }; // Deprecated: use S(1, 2) instead


So after this DIP we would write

S s = S(1, 2);

instead.

However, would

S s = (1, 2);

be allowed inferring the type?


Would there be case where this type of initialization would mask the constructor of a type or vice versa?

Ex.

struct S
{
    int a, b;
    this(int bp, int ap)
    {
        a = ap;
        b = bp;
    }
}

writing

S s = S(1, 2);

what would it pick?

On 2/13/2020 1:47 AM, IGotD- wrote:
> However, would
> 
> S s = (1, 2);
> 
> be allowed inferring the type?

No. But you can write:

  auto s = S(1, 2);


> Would there be case where this type of initialization would mask the constructor of a type or vice versa?

The constructor takes precedence.

> struct S
> {
>      int a, b;
>      this(int bp, int ap)
>      {
>          a = ap;
>          b = bp;
>      }
> }
> 
> writing
> 
> S s = S(1, 2);
> 
> what would it pick?

The constructor.

On Thursday, 13 February 2020 at 09:56:27 UTC, Walter Bright wrote:
>
>> Would there be case where this type of initialization would mask the constructor of a type or vice versa?
>
> The constructor takes precedence.
>
>> struct S
>> {
>>      int a, b;
>>      this(int bp, int ap)
>>      {
>>          a = ap;
>>          b = bp;
>>      }
>> }
>> 
>> writing
>> 
>> S s = S(1, 2);
>> 
>> what would it pick?
>
> The constructor.

Which, for the record, is the current behavior. Unfortunately, the struct literal documentation only mentions opCall. I'll submit a PR.

https://dlang.org/spec/struct.html#struct-literal

On Thursday, 13 February 2020 at 09:47:13 UTC, IGotD- wrote:
> According to the DIP
>
> This will be deprecated.
>
> struct S { int a, b; }
>
> S s = { 1, 2 }; // Deprecated: use S(1, 2) instead
>
>
> So after this DIP we would write
>
> S s = S(1, 2);
>
> instead.
>
> However, would
>
> S s = (1, 2);
>
> be allowed inferring the type?

This is allowed today:

    auto s = S(1, 2);

This as well:

    alias args = AliasSeq!(1, 2);
    auto s = S(args);
    S s2 = S(args);

If this was accepted:

    alias args = AliasSeq!(1, 2);
    S s = args;

We could also write:

    S s = AliasSeq!(1, 2);

And also, if Timon's proposal [1] is accepted, we would get built-in syntax for AliasSeq-es, so we would finally be able to write:

    S s = (1, 2);

[1]: https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md

>
> Would there be case where this type of initialization would mask the constructor of a type or vice versa?
>
> Ex.
>
> struct S
> {
>     int a, b;
>     this(int bp, int ap)
>     {
>         a = ap;
>         b = bp;
>     }
> }
>
> writing
>
> S s = S(1, 2);
>
> what would it pick?

A user-defined constructor prevents the generation of a compiler-synthesized one.

In the code above, the result is `S(2, 1)`, i.e. `1` is assigned to `S.a` and `2` to `S.b`. This DIP won't change anything in this regard.