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

===================================
**THIS IS NOT A DISCUSSION THREAD**

Posts in this thread must adhere to the feedback thread rules outlined in the Reviewer Guidelines (and listed at the bottom of this post).

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

That document also provides guidelines on contributing feedback to a DIP review. Please read it before posting here. If you would like to discuss this DIP, please do so in the discussion thread:

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

==================================

You can find DIP 1031 here:

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

The review period will end at 11:59 PM ET on February 27, or when I make a post declaring it complete. Feedback posted to this thread after that point may be ignored.

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

==================================
Posts in this thread that do not adhere to the following rules will be deleted at the DIP author's discretion:

* All posts must be a direct reply to the DIP manager's initial post, with only two exceptions:

    - Any commenter may reply to their own posts to retract feedback contained in the original post

    - The DIP author may (and is encouraged to) reply to any feedback solely to acknowledge the feedback with agreement or disagreement (preferably with supporting reasons in the latter case)

* Feedback must be actionable, i.e., there must be some action the DIP author can choose to take in response to the feedback, such as changing details, adding new information, or even retracting the proposal.

* Feedback related to the merits of the proposal rather than to the contents of the DIP (e.g., "I'm against this DIP.") is allowed in Community Review (not Final Review), but must be backed by supporting arguments (e.g., "I'm against this DIP because..."). The supporting arguments must be reasonable. Obviously frivolous arguments waste everyone's time.

* Feedback should be clear and concise, preferably listed as bullet points (those who take the time to do an in-depth review and provide feedback in the form of answers to the questions in this document will receive much gratitude). Information irrelevant to the DIP or is not provided in service of clarifying the feedback is unwelcome.

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

Yesss, let's do it. This syntax is a C relic only kept alive by the lack of viable alternatives. Named arguments functionality subsumes it completely, especially if it's usable with implicit struct constructors.

More downsides to {}:

- completely bypasses the constructor
- no way to disable default initialization of fields, making it silently broken if fields are added
- it's an expression whose validity is dependent on the type it's being assigned to, and those are always awkward with templated functions
  - hence there's no way to set its type without creating extra variables
- the syntax awkwardly clashes with object literals in dynamic languages, as well as hashmaps

I don't oppose what's being proposed, but I do have feedback on the DIP.

> Having two equivalent means to acheive the same effect is a pointless redundancy in a language. Even worse, it engenders bikeshedding debates about which approach is "better". It's better to have one way of achieving the effect in that it reduces the complexity of the compiler, the specification, and efforts to teach the language.

That doesn't provide much motivation for removing an existing feature from the language. There might be reasons to prefer one approach over the other depending on what you're doing. I think it's motivated by DIP 1030, in which case that should be the rationale.

> Breaking Changes and Deprecations

The only example is this:

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

That's a simple case to handle, but is every case of breakage going to be this simple?

This DIP, nor the prerequisite DIP 1030, mention that structs will have a default literal syntax that allows named parameters when a constructor is absent.

DIP 1030 specifically mentions only function and template parameters.

DIP 1031 hints that DIP 1030 must be accepted, so therefore it must have some bearing on this. However, one might interpret that to mean you have to define a constructor to get named parameter syntax (which, if true, would be a huge breaking change that needs to be mentioned). Also, the single example does not involve named parameters whatsoever.

It needs to be made clear that one can use an equivalent syntax to initialize a struct that could previously use an initializer. I'm assuming this is the case, and if not, I would reject this DIP.

e.g. "Struct literals will be modified to allow named parameters, which follow the spec of DIP 1030. Any parameter not provided will receive a default value according to the .init value of the struct."

And a more definitive example:

struct S
{
   int a;
   int b;
}

S s = {b: 5}; // Deprecated, use S(b: 5) instead

-Steve

On 2/13/20 8:23 AM, Steven Schveighoffer wrote:
> This DIP, nor the prerequisite DIP 1030, mention that structs will have 

That should have said:

*Neither* this DIP, nor the prerequisit DIP 1030, mention ...

-Steve

On 2/13/2020 2:06 AM, bachmeier wrote:
> I don't oppose what's being proposed, but I do have feedback on the DIP.
> 
>> Having two equivalent means to acheive the same effect is a pointless redundancy in a language. Even worse, it engenders bikeshedding debates about which approach is "better". It's better to have one way of achieving the effect in that it reduces the complexity of the compiler, the specification, and efforts to teach the language.
> 
> That doesn't provide much motivation for removing an existing feature from the language. There might be reasons to prefer one approach over the other depending on what you're doing. I think it's motivated by DIP 1030, in which case that should be the rationale.

Being completely redundant is a good motivation.


>> Breaking Changes and Deprecations
> 
> The only example is this:
> 
> S s = { 1, 2 }; // Deprecated: use S(1, 2) instead
> 
> That's a simple case to handle, but is every case of breakage going to be this simple?

As far as I know, yes.

Typo in the rationale, it's achieve, not acheive.