Sprinkle some more readonly around

[stephentoub]

No description provided.

[ghost]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

---

null

Author:	stephentoub
Assignees:	stephentoub
Labels:	area-Meta
Milestone:	-

[KirillKornienko]

All the time I'd like to ask if there's a performance/gc difference between a "read-only" or non-read-only field? Can this be optimized at runtime (e.g. null-checking if readonly field is already set and can never be null after that)? Or is it just syntax to reflect the programmer's intent?

[stephentoub]

if there's a performance/gc difference between a "read-only" or non-read-only field?

There can be a perf benefit, in particular for static fields.

[tannergooding]

Changes to types in my ownership area look correct.

Generally scanned the other changes too and they also look sensible, but should likely get secondary eyes from the respective owners.

[jeffhandley]

Scanning through, this all looks straightforward and I presume the compiler would have yelled if anything was amiss.

@stephentoub I'm curious how you went about identifying these sites. Are there more layers of sprinkles to add?

[stephentoub]

I presume the compiler would have yelled if anything was amiss.

Mostly. The main risk would be making a field containing a mutable struct readonly; the compiler wouldn't complain but it could have bad behavioral impact.

I'm curious how you went about identifying these sites. Are there more layers of sprinkles to add?

IDE0044. Unfortunately it's currently too noisy for us to enable outright, but I did locally and addressed many of the valid cases.

[marek-safar]

Does not this break serialization support?

[stephentoub]

I don't believe it does. @GrabYourPitchforks?