Proposal: dotnet/csharplang#1710

This issue is a place to collect test ideas and track their validation. Use the compiler test plan as a tool for brainstorming.

• write speclet
• update compiler test plan
• validate with LangVersion 7.3

Methods

• struct instance methods
• struct static methods (should error)
• class/interface static/instance methods (should error)
• ref/ref readonly returning methods
• Inherited object members should be considered readonly
• 'readonly partial' methods
• 'readonly partial' where one of declaration or implementation is missing keyword (error)
• readonly on new ToString()

Properties

• struct readonly getters
• struct readonly setters (not auto-implemented)
• struct static properties with readonly accessors (should error)
• class/interface properties with readonly accessors (should error)
• expression bodied properties int P readonly => 42; (should error)
• indexers (allow)
• readonly getter in a readonly property? (should be disallowed)
• readonly on int P { readonly get; set; } allowed
• getter implicitly readonly for all auto-props
• int P { readonly get; } not allowed -> readonly int P { get; }

Misc

• Constructors (disallow)
• Operators (disallow)
• Delegates (disallow)
• Field-like events (disallow)
• Manually implemented events (allow)
• lambdas/local functions (error)
• explicit interface implementations (should allow)
  - [ ] SymbolDisplay on methods and property/indexer/event accessors Readonly members SymbolDisplay/MetadataAsSource #34650
  - [ ] IsDeclaredReadonly on ISymbol or IPropertySymbol/IMethodSymbol Public API design for readonly properties and events in C# #34213

Semantic

• Calling readonly methods from readonly methods
• Calling non-readonly struct methods from readonly methods
• Calling a non-readonly method on a reference type field from a readonly method
• Variants of these which use different combinations of properties and methods
• Assignment to this
• Reference to instance fields in readonly member
  • Assignment is an error
  • Invocation w/ instance field as receiver causes copy when type is non-readonly struct
• Invocation of non-readonly method or getter on this inside a readonly member causes copy and a warning. Non-readonly setter access on this or a value typed field is an error.
• Unary increment/decrement operators on fields are errors
• Compound assignment on fields is an error
• Round-tripping through metadata
• Error to take ref to this in readonly member
• Property assignment:
  • Disallow on non-readonly instance properties on this or value-typed fields
  • Allow on static or readonly properties, or properties on reference-typed fields
  • Compound assignment behavior should be consistent with a getter-then-setter access
    https://sharplab.io/#v2:EYLgZgpghgLgrgJwgZwLRKgEwPYDsA2AnqgLYQnAQLIA0MIAlvjZiANQA+AAgAwAEXAIwBuALAAoDDgKE+yGAjgBjGHwDKEgN4S+uvg1yqACn018A5hFVmuAdj49hAXzlXTfF0517vurgBY+AFkACgN1OQBKX1MYvT4YAAsGZAA6EwBePn8AJjFxePi0zOy8mK8Cn3EKiXlFFXUcrRiDY3dLawF7RxdkNzNPGJipPCIBQNDwtRy5HOjK3W0FwoB6FaSU9L4s3PzCvTXkHK2dsuX4gH1thOTivf2bzZM2LLP4iviJJyA=

IDE

- [ ] Extracting a method from a readonly method should produce a readonly method #34647
- [ ] Suggestion to make a member readonly when it is called on a ref readonly receiver #34648
- [ ] WRN_ImplicitCopyInReadOnlyMember should have a suggestion to make the callee readonly if possible #34649
- [ ] WRN_ImplicitCopyInReadOnlyMember should have a suggestion to make an explicit copy of the receiver

• Offered in completion in existing member
  - [ ] Metadata as source Readonly members SymbolDisplay/MetadataAsSource #34650

Major sections of work (ideally PRs will not cover more than one of these)

• Parsing of readonly method and property syntax (mostly just testing)
• IsReadOnly API on MethodSymbol
  • In the case of properties, is prop.GetMethod.IsReadOnly acceptable design, or is it confusing to have prop.IsReadOnly potentially return a different value than prop.GetMethod.IsReadOnly?
• Flow analysis to prevent mutation of this in readonly member implementation
  • maybe the analysis used for in params or readonly struct can just be reused?
• Error on invalid usage of readonly
  • Any method or property without a this parameter (i.e. statics)
  • Any member inside a non-struct declaration (i.e. class, interface)
• Emit tests to demonstrate that expected metadata (IsReadOnly, modopt, modreq) and optimizations (reduced value copying) are present in IL

- [ ] Should some synthesized methods be marked as readonly? (discussion) #36587

• Should we disallow readonly members on readonly structs, since redundant? Or maybe we create an IDE fixer?
  • Resolution: Should be allowed, based on the principle that changing struct to readonly struct on a type where all members are marked readonly shouldn't result in a compile error.