The short version would be: because nobody has supported, spec'd, designed, implemented, tested, documented, translated and supported that feature.
The longer version would relate to why to do it, given that it can be achieved indirectly with the readonly
field - what benefit would it add.
For classes, it turns out to be relatively minor. Note that there is an [ImmutableObject(true)]
attribute that can be used, but no features or frameworks really have a use for it, so ... nobody uses it.
Where this gets really interesting is in the current ref
work that is happening in the corefx experimental branch. In particular, "readonly structs" are likely to be a thing soon. There's a reason for this, which is that:
- they enable good
readonly ref T
support (which is necessary forReadOnlySpan
, which is necessary for theSpan
stuff, which is necessary for the "unifying managed an unmanaged memory stuff", whi