DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion

[Jonathan M Davis]

On Friday, February 21, 2020 8:19:34 AM MST Jonathan M Davis via 
Digitalmars-d wrote:
> On Saturday, February 15, 2020 5:50:15 AM MST Guillaume Piolat via
>
> Digitalmars-d wrote:
> > 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.
>
> I tend to forget that the syntax exists, and I never use it, but it's
> probably less error-prone than using the constructor syntax with a struct
> that has no constructors, since it's at least lining up the field
> initializers with the fields by name, meaning that if fields are added,
> removed, and/or rearranged over time, you won't end up with existing code
> initializing the wrong fields.
>
> If you use the constructor syntax with a struct that has no constructors,
> then it just sets the fields in order, and if you provide fewer
> initializers than there are fields, then the rest just get
> default-initialized. And while that can be fine when you first declare
> the struct, it can be very error-prone if the struct's fields are ever
> changed later, since existing code may still compile but then end up
> setting the wrong fields. It's why I pretty much always declare
> constructors for structs even if they're just POD types where all of the
> members are public.

Ouch. I didn't read carefully enough. I wasn't aware that the brace style
for struct initialization works without providing field names. That just
seems redundant with the constructor syntax, and it has all of the same
problems that you get with using the constructor syntax without a
constructor, which is something that I'm inclined to think is bad practice
due to how error-prone it can be as code is changed over time.

- Jonathan M Davis