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

Mathias Lang pro.mathias.lang at gmail.com
Fri Feb 14 05:53:08 UTC 2020


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":
>
> https://github.com/dlang/DIPs/blob/c0c1c9f9665e0bc1db611f4e93e793d64451f763/DIPs/DIP1031.md


I think this is heading in the right direction, however I see 
three issues:

1) The type name has to be repeated.
     So as mentioned, `Foo f = (42, 84);` would be more readable 
than `Foo f = Foo(42, 84);`.
     This gets worse when a struct contains nested struct 
definitions, as Andre pointed out (here: 
https://github.com/dlang/DIPs/pull/169#issuecomment-532830320).

2) It's actually part of 1, but I wanted to make it a separate 
issue because it's important. Not *all* usages of struct 
initializer can be replaced by the constructor syntax. For 
example:
```
--- definition.d
module definition;

struct Foo
{
     private struct Bar
     {
         int a;
         int b;
     }

     Bar ber;
}

--- main.d
module main;
import definition;

void main ()
{
     Foo f = { ber: { a: 42, b: 84 } };
}
```

To replace this usage, one has to use `typeof(Foo.ber)`. Even 
more verbose.

3) It's way, way too early to deprecate them. There is currently 
*no replacement available*. Some libraries try to keep 
compatibility for many versions (e.g. Vibe.d) and some projects 
tests with compilers that go way back (GDC-9 is the 2.076 FE and 
still used).

I tried to deprecate the `body` keyword after `do` has been in 
for 10 releases, and had to revert it 
(https://github.com/dlang/dmd/pull/10763) because it still causes 
too much breakage.

This fits your own definition of "shuffling things around to no 
benefit". I'm always happy to clean up the language, but it's a 
long and tedious process, and something that takes a lot of time 
in itself if we want to keep our users.


More information about the Digitalmars-d mailing list