Define rules for "readonly" in struct types #1339
Description
See https://github.com/dotnet/csharpstandard/pull/673/files#r1510548259
The language that describes what readonly allows and prohibits needs more work.
- There are instances of the phrase "It is a compile-time error to attempt to modify the state of an instance struct variable via a readonly property declared in that struct." in the standard. This isn't defined as well as it should be.
- A compiler may allow
readonlymembers to invoke non-readonly members on "the same instance" of astructby creating a defensive copy and invoking the mutating member on the defensive copy. - A readonly member can't change the value of a member, but can change the fields that are members of that member. (not specese, but that describes the issue)
Copied from the linked discussion:
under classes modifiers are generally described in subclauses under §15.3 Class members.
That same pattern can be repeated here with the current content of §16.3 Struct members becoming §16.3.1 General and adding §16.3.2 The readonly modifier.
In §16.3.2 the rules for readonly members can be given (not proposed text):
- They cannot mutate the state of the struct instance
- They may mutate the static state of the struct
- And the (subjectively) ugly one, a readonly member may call a mutating member (of the same instance only?) but any mutations made must not be observable after the call. This could in terms of the compiler strategy of “defensive copies”, see “Defensive” copies – standardising a compiler strategy or language semantics? #1053, or not.
This would provide a single place for defining what a readonly member. The additional per-member differences could follow in §16.3 subclauses or remain as they are in §16.4 subclauses.
In addition to the normative language, an example (as discussed here would be useful as well.