I kind of don't appreciate the fact I can actually reassigned a readonly field during construction time. Both static and instance versions.
I only recent discovered this feature. It was by accident, as I was trying to track an unrelated bug.Code:class foo { public static readonly bool sfield = false; public readonly bool rfield = false; static foo() { sfield = true; } public foo() { rfield = true; } } static void Main() { foo bar = new foo(); Console.WriteLine(bar.rfield && foo.sfield); // returns 'true' Console.ReadLine(); }
I don't know, if the field assignment must include business logic, I could use this feature as a means to support a default value, for instance. But frankly that just doesn't make much sense, since implementing default state is easy as pie and I would want anyways to contain the whole of the business logic within the ctor and not spread it also to the field declaration.
But more than that, this feature doesn't make much sense. Purely from the point of view of language semantics, I'm effectively changing a readonly field previous assignment. This can be permissible due to the semantics of the readonly keyword specifically. But doesn't make much sense on a more general perspective of how the language should illustrate intent.
What do you think? Makes sense to file in a bug report suggesting the issuing of a compile-time warning when explicitly reasigning readonly fields in ctors (no warning would be issued if the explicit assignment happened on just the ctor or at the declaration point)?