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

[Steven Schveighoffer]

On 2/15/20 6:54 PM, Walter Bright wrote:
> On 2/15/2020 6:39 AM, Steven Schveighoffer wrote:
>>  From the perspective of the user, the complications in the compiler 
>> or library are of zero significance.
> 
> The complication is in the language. This affects the user:
> 
> 1. the language is larger
> 2. user has to decide "should I do it the A way or the B way?"
> 3. documentation is longer

All these points apply to for loops and foreach loops as well. All of 
these can be done with while loops.

Yet, we don't want to remove them because they provide a good readable 
syntax for what is required in most cases.

In my opinion, when you are adding features, you have a different bar to 
cross than when you are removing them. If adding, does the feature 
provide enough benefit syntactically over existing mechanisms to justify 
a language change. If removing, is there an alternate feature that can 
mimic it to a sufficient degree that we can remove it with a 
straightforward positive conversion?

Look at octals and hex strings. Both of these were implemented via a 
library call that provided equivalent operation. The syntax sugar was 
gone, but octals were confusing and error prone in their current state 
(being more verbose there with an `octal!` was a benefit), and hex 
strings simply weren't worth an entire language feature for it when CTFE 
could do exactly the same thing with a single call (newCTFE will help 
here too).

In this DIP, we are exploding the verbosity and repetitiveness to an 
uncomfortable degree, which frankly wasn't even necessary before. The 
brace syntax is beautifully minimal.

If we can alleviate that concern, I think there would be no problem to 
remove this feature.

> 4. anyone writing a book/tutorial on D has to become proficient with it

Really? You have to be proficient in D struct initializers to write a 
book? I'm pretty sure I have at least 2 D books without this in it.

I actually don't ever use braced struct initializers. But the use cases 
that have been provided are pretty compelling, and your workarounds have 
not been. At least not enough to remove the syntax sugar provided 
without a comparable replacement.

> 5. introduces bugs (such as the one just noticed that the { } allows 
> access to private fields)

Is that really a bug? Struct literals have this access as well.

I'll also note that Mathias' example was not a private data member, but 
a private type (i.e. Voldemort type) with public members. His point was 
that everything being initialized was public, except the name. Which the 
new syntax requires whereas the old does not.

.tupleof provides private access also. I think there are many libraries 
that probably depend on this, so you may want to deprecate that slowly.

-Steve