search

dotnet / csharplang

The official repo for the design of the C# programming language
11.61k stars 1.03k forks source link

Champion: readonly object initializers #1684

Closed jaredpar closed 3 years ago

jaredpar commented 6 years ago

This proposal will extend object initializers to allow assignment of readonly fields and get only auto-implemented properties.

Proposal link https://github.com/dotnet/csharplang/pull/1683

LDM history:

kkm000 commented 6 years ago

@CyrusNajmabadi

AFAICT, every example showing builders showed them as structs. My post was meant to be understood withing that context.

I am sorry, I must have misunderstood you entirely. So .Build() would essentially ref-return a stack-allocated readonly struct it would build, while being a zero-length struct itself. That could work, if the builder would avoid the requirement to initialize all members in a readonly struct in its constructor.

How is it any less clear to do new State(localSymbol: Whatever) vs. new State { LocalSymbol = Whatever }

A mandatory human-generated trivial multiple-argument constructor that may possibly have one and only one form for the case of readonly struct that can be passed by in reference, versus no such restriction on the existing struct.

you are not willing to engage on an actual explanation of why you believe that is.

My unwillingness to discuss the proposal has to do solely with the fact that it has been dropped. I cannot agree more that this was a very good proposal. Even syntactic ambiguity (which exists, for example, in the similar C++ initializer) could have been avoided, as in field assignment expression new T() { Field=expr } opposed to a construction expression new T { Field=expr }.

CyrusNajmabadi commented 6 years ago

A mandatory human-generated trivial multiple-argument constructor that may possibly have one and only one form for the case of readonly struct that can be passed by in reference, versus no such restriction on the existing struct.

I really have no idea what this is trying to say. You've made claims of clarity and how intent is hidden. But i cannot see how it's any less clear to have new State(localSymbol: Whatever). To which users is that unclear? It's entirely idiomatic. It's self documenting. It's even shorter than the property-initializer form (though i don't really think that's even relevant).

Where is the lack of clarity? What intent is hidden?

I am sorry, I must have misunderstood you entirely.

No worries. Perhaps there has been a misunderstanding of much of the rest of hte proposal? As well as how structs/constructors already fit into the language. It seems like you may be commenting based on other misunderstandings and misapprehensions about things work.

Even syntactic ambiguity (which exists, for example, in the similar C++ initializer) could have been avoided

Sorry, it's unclear to what you're referring to. What syntactic ambiguity problem are you trying to address?

333fred commented 3 years ago

This is covered by init accessors. Closing out.