Update semi auto props spec around readonly backing field for init-only#5582
Update semi auto props spec around readonly backing field for init-only#5582333fred merged 2 commits intodotnet:mainfrom
Conversation
| - If the auto-property has no set accessor, the backing field is considered `readonly` ([Readonly fields](classes.md#readonly-fields)). Just like a `readonly` field, a getter-only auto-property can also be assigned to in the body of a constructor of the enclosing class. Such an assignment assigns directly to the readonly backing field of the property. | ||
| + If the auto-property has semicolon-only get accessor without a set accessor, the backing field is considered `readonly` ([Readonly fields](classes.md#readonly-fields)). Just like a `readonly` field, a getter-only auto property can also be assigned to in the body of a constructor of the enclosing class. Such an assignment assigns directly to the backing field of the property. | ||
| + If the auto-property has semicolon-only get accessor (without a set accessor or with an init-only accessor), the backing field is considered `readonly` ([Readonly fields](classes.md#readonly-fields)). Just like a `readonly` field, a getter-only auto property can also be assigned to in the body of a constructor of the enclosing class. Such an assignment assigns directly to the backing field of the property. | ||
| ``` |
There was a problem hiding this comment.
lol. i got so confused fro a second. i was going to say these two seem almost identical and should be merged. then i realized i was looking at a diff 🗡️
There was a problem hiding this comment.
Yeah reviewing a diff in a diff hurts eyes 😄
There was a problem hiding this comment.
hrmm... does teh constructor actually assign to the field? it doesn't go through the init-setter?
There was a problem hiding this comment.
@CyrusNajmabadi I think the spec is now wrong regarding this point. I focused more on the first sentence. We need to adjust.
There was a problem hiding this comment.
yeah, i think the second sentence needs to be clear that it's only covering the {get;} case and not the init case.
There was a problem hiding this comment.
Actually it seems like it's accurate already? It mentions getter-only auto property, so it doesn't apply for the "with an init-only accessor" part of the previous sentence.
There was a problem hiding this comment.
right. i think the language is correct, but potentially confusing in context. i wasn't sure if getter only meant: only { get; }, or also somehow applied to get+init (since hte prior sentence covers that). I feel like it could use with jsut a little clarity, only to avoid confusion.
Co-authored-by: CyrusNajmabadi <cyrus.najmabadi@gmail.com>
…dates * upstream/main: Add example of when field initializers will not be run for option 3. Correct link Added LDM notes for January 3rd, 2022. Update README.md Update LDM agenda Fix line wrapping (dotnet#5589) Update raw-string-literal.md 'record struct' constructor requires 'this' initializer that calls primary constructor or explicit constructor (dotnet#5562) Tweak readonly backing field wording (dotnet#5583) Update semi auto props spec around readonly backing field for init-only (dotnet#5582) Spec change around backing field being readonly (dotnet#5575)
* upstream/main: Update LDM agenda Added LDM Notes for January 5th, 2022. Update the required members spec (dotnet#5566) Add example of when field initializers will not be run for option 3. Correct link Added LDM notes for January 3rd, 2022. Update README.md Update LDM agenda Fix line wrapping (dotnet#5589) Update raw-string-literal.md 'record struct' constructor requires 'this' initializer that calls primary constructor or explicit constructor (dotnet#5562) Tweak readonly backing field wording (dotnet#5583) Update semi auto props spec around readonly backing field for init-only (dotnet#5582) Spec change around backing field being readonly (dotnet#5575)
Addresses #5575 (comment)
cc @RikkiGibson @AlekseyTs @333fred @CyrusNajmabadi @jnm2