Field-backed properties: readonly backing field #74922
Conversation
dotnet-issue-labeler
bot
added
Area-Compilers
untriaged
| } | ||
| // - The property has no set accessor (but may have an init accessor) and | ||
| // the get accessor, if any, is automatically implemented. | ||
| else if ((!hasSetAccessor || isInitOnly) && (!hasGetAccessor || hasAutoPropertyGet)) |
There was a problem hiding this comment.
Should the field also be readonly if all manually implemented get and set accessors are declared readonly?
There was a problem hiding this comment.
I have a slight leaning towards "no", but not a strong opinion.
There was a problem hiding this comment.
It's not valid to declare both accessors as readonly, you'd have to declare the containing property as readonly instead, which would make the field readonly per these rules.
There was a problem hiding this comment.
Declaring both as readonly is an error, but we may want to treat the backing field as readonly in the following case:
struct S
{
object P { get; readonly set { } }
}There was a problem hiding this comment.
I think a more compelling example is:
struct S
{
object P { readonly get => field; init; }
}There was a problem hiding this comment.
FWIW, I can't think of a case where things are made worse by the backing field not being readonly, in cases involving the accessors being marked readonly but not the containing type or property.
There was a problem hiding this comment.
I've added a PROTOTYPE comment and a test for now.
| } | ||
| // - The property has no set accessor (but may have an init accessor) and | ||
| // the get accessor, if any, is automatically implemented. | ||
| else if ((!hasSetAccessor || isInitOnly) && (!hasGetAccessor || hasAutoPropertyGet)) |
There was a problem hiding this comment.
I have a slight leaning towards "no", but not a strong opinion.
| <Q5>k__BackingField: True | ||
| <Q6>k__BackingField: {{useReadOnlyType}} | ||
| <Q7>k__BackingField: True | ||
| <Q8>k__BackingField: {{useReadOnlyType}} |
There was a problem hiding this comment.
It feels like in the case useReadOnlyType: false, useReadOnlyMember: true, all accessors are readonly, yet the backing field is not readonly. That seems a little strange. I guess it doesn't really matter, though.
There was a problem hiding this comment.
Yes, this is an example of the case I was expecting in #74922 (comment).
From proposal: