The following code is from actual real world:

VkPipelineViewportStateCreateInfo viewportStateInfo = {
	viewportCount : 1,
	pViewports    : [ {0f, 0f, 1920f, 1080f, -1f, 1f} ],
	scissorCount  : 1,
	pScissors     : [ {{0, 0}, {1920, 1080}} ],
};

If the brace-style struct initializers get deprecated this is what I have to write:

auto viewportStateInfo = VkPipelineViewportStateCreateInfo(
	viewportCount : 1,
	pViewports    : [ VkViewport(0f, 0f, 1920f, 1080f, -1f, 1f) ],
	scissorCount  : 1,
	pScissors     : [ VkRect2D(VkOffset2D(0, 0), VkExtent2D(1920, 1080))) ],
);

The following is what it looks like if I use parameter names as well, and it's not hard to imagine having to write code like this if someone has complicated nested structures:

auto viewportStateInfo = VkPipelineViewportStateCreateInfo(
	viewportCount : 1,
	pViewports    : [ VkViewport(x:0f, y:0f, width:1920f, height:1080f, minDepth:-1f, maxDepth:1f) ],
	scissorCount  : 1,
	pScissors     : [ VkRect2D(offset: VkOffset2D(x:0, y:0), extent: VkExtent2D(width:1920, height:1080))) ],
);


Absolutely not ideal. Doesn't scale. Too verbose.
This feature should be improved instead of making it deprecated. I've never seen someone getting confused by brace-style syntax. I have also yet to discover any deal breaking issues about this feature, and it doesn't seem complicated to support **at all**.
This would also break a good amount code and that is rather hard to automate by conventional text editing tools. (if only people cared about dfix huh...)

Besides, I don't want my D code to look like java. I've had enough of that.

On Sunday, 16 February 2020 at 06:27:32 UTC, H. S. Teoh wrote:
> What's the point of lightning fast generation of poor quality code? Okay, during development it's good to have fast turnaround times. But what when it's release time and I want to squeeze the last bit of juice from the generated code?

I don't know about you, but I spend like 99.9% of my time in the development phase and 0.1% in the final release build phase. In a lot of cases DMD produces code that's more than good enough, so I don't even both with LDC, but it really doesn't add anything to my development time to add a final call to LDC. If you could alias DMD -O to call LDC, you wouldn't notice the difference.

On 2/15/2020 10:09 PM, Paul Backus wrote:
> On Sunday, 16 February 2020 at 05:57:22 UTC, Walter Bright wrote:
>> Left unsaid in all this is the static initializer syntax can only be use for statics, and even then only for structs without a constructor.
> 
> It actually works for dynamic initialization too:
> 
>> The static initializer syntax can also be used to initialize non-static variables. The initializer need not be evaluable at compile time.
> 
> Source: https://dlang.org/spec/struct.html#dynamic_struct_init

Yes, you're right. My mistake.

On 2/16/2020 11:38 PM, Nathan S. wrote:
> Would removing support for brace-style struct initializers significantly simplify or speed up some portion of DMD?

No.

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.

- 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