@colejohnson66: The record is maybe one part. That I cannot make a class readonly the other.
In the end I'm "complaining" about the assymmetric behavior of readonly struct and readonly class/record.

As @HaloFour suggests an analyzer would one solution, to have it directly forbidden by the language another.
I understand that the language team is hesitating update the language.

It's not asymetric. readonly on a struct (or a struct member) allows the compiler to know that if an instance of that struct is in a readonly location (like a readonly field) that it does not need to make pessimistic copies of that value before operating on that instance.

There is no equivalent for classes. If a class is assigned into a readonly field, no pessimistic copies need to happen (as the storage location itself cannot change).

no pessimistic copies...

Understood. But if it needs to do pessimistic copies is something the runtime decides, right? It is hinted by the readonly modifier.
Having it for the class would only be a language feature which can of course also be done by an analyzer.

Assuming the class would get the readonly modifier, wouldn't this be some sort of optimization hint for the future to let the runtime decide if it could make a struct out of it and treat it as a value type?

But if it needs to do pessimistic copies is something the runtime decides, right? It is hinted by the readonly modifier.

No. It is the responsibility of roslyn and done at initial compile.

@333fred: Alright. Thanks.