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

[aliak]

On Friday, 14 February 2020 at 05:53:08 UTC, Mathias Lang wrote:
> 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);`.

You have auto?


>     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 } };
> }
> ```

This seems like a hole indeed. I wonder if it's worth considering 
though. My first thought is why is something that needs to be 
publicly constructed, not public? This looks fishy.

There's a very valid use case when it comes to returning 
voldermort types that match a specific interface (i.e. ranges), 
but I've never seen anyone construct them. And over here we have 
a declaration of a type, why is only the name private?

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

Yes, the deprecation should only happen after there's a 
replacement indeed (in general, not sure of that specific hole 
you showed above though).