In looking at the source for the KeyValuePair<TKey, TValue> struct, the private member fields are only ever written to by the constructor. Is there a design consideration of some sort as to why these are not marked readonly?
views:
38answers:
1
+3
A:
I do not believe there was any explicit design decision here. It was almost certainly an oversight by the original author of the code.
Also at the time of this types' authoring, the use of readonly was a bit controversial for this scenario. A significant number of people felt it was bad practice to use readonly on a non-immutable field. So much so that an FxCop rule was added to enforce this practice (CA2104). The type author could simply played by the rules of the time.
JaredPar
2010-06-08 14:36:23
You saw it "was" controversial. Has the controversy been settled?
Jesse C. Slicer
2010-06-08 15:30:40
@Jesse, it's still a bit controversial overall. Luckily my last few groups have almost universally agreed that using `readonly` is correct so I tend to feel like it went away. But really I'm sure it's still a hot issue in a couple of places.
JaredPar
2010-06-08 15:34:36
@Jared, thanks. I've been making **all** my fields `readonly` by default (much like starting my classes as `sealed` by default) and only carefully removing it if I find my design calls for mutability within the class.
Jesse C. Slicer
2010-06-08 15:44:33
@Jesse, this is the approach I favor as well.
JaredPar
2010-06-08 15:50:40