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

[Mathias Lang]

On Friday, 14 February 2020 at 07:09:05 UTC, aliak wrote:
> 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?

The real inconvenience shows up as you nest structure, which was 
in the second part of the quote.

Consider `auto f = Foo(a: SomeType(b: SomeOtherType(x: 42)));`, 
it is not quite as readable as the struct literal alternative, 
and there's no way to use `auto` here, even though the expected 
type is known to the compiler and unambiguous.

And I didn't even mention templates! Imagine if a struct is an 
aggregate of other templated struct, e.g. `struct Aggregated (T, 
TV = DefaultValue) { Foo!T f1; Bar!T f2; xvector!(T, TV) f3; }`.
Have fun turning a struct literal for this into something that 
spells out the type.

I usually keep my type names verbose but my fields name short, 
and use struct literal all over the place. It leads to expressive 
code that is easy to read and easy to write, and feels familiar 
to people used to read JSON or YAML.

> [...]
>
> 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?
>

I would strongly advise against trying to decide what is a 
"valid" use case. Just because someone approach a problem 
differently doesn't mean their solution is invalid.


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

The point was that when we replace a feature, it should take 
years before the old version is deprecated if we want to be taken 
seriously as a language.