tooslow.md

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:

1. they enable good readonly ref T support (which is necessary for ReadOnlySpan<T>, which is necessary for the Span<T> stuff, which is necessary for the "unifying managed an unmanaged memory stuff", which is part of the "allow library authors more access to awesome performance" stuff)
2. they solve a longstanding performance issue relating to how readonly fields that are structs force a memory copy when any method is accessed even if every field is readonly, due to the way that arg0 (this) allows reassignment

I plan to blog on these soon as part of the "spans and refs" stuff (part 1, part 2)