• Mike Parker (53/53) Feb 12 2020 This is the feedback thread for the first round of Community
• FeepingCreature (16/18) Feb 12 2020 Yesss, let's do it. This syntax is a C relic only kept alive by
• bachmeier (11/18) Feb 13 2020 That doesn't provide much motivation for removing an existing
• Walter Bright (3/23) Feb 13 2020 As far as I know, yes.
• Steven Schveighoffer (23/23) Feb 13 2020 This DIP, nor the prerequisite DIP 1030, mention that structs will have
• Steven Schveighoffer (4/5) Feb 13 2020 That should have said:
• Patrick Schluter (1/1) Feb 13 2020 Typo in the rationale, it's achieve, not acheive.

Mike Parker <aldacron gmail.com> writes:

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.

FeepingCreature <feepingcreature gmail.com> writes:

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

bachmeier <no spam.net> writes:

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?

Walter Bright <newshound2 digitalmars.com> writes:

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.

Steven Schveighoffer <schveiguy gmail.com> writes:

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

Steven Schveighoffer <schveiguy gmail.com> writes:

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

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

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