A few notes on the readonly field vs readonly property post...

First, Tom (not Ted) pointed out that I removed his use of [DebuggerStepThrough] on the get accessor. I did it to simplify things, but it is a useful thing to do.

Maurits asked, "What would be the drawback of rearchitecturing C# to make public variables compile to public get-only properties?".

Well, I guess I don't see a lot of advantage in doing that, so I guess the chief drawback I'd see is "insufficient utility versus the added complexity". We did play around with different syntaxes that could be used to write properties without having to write the accessors, but it turned out that they either 1) Didn't cover the important scenarios or 2) were as complex as writing the property. We elected not to do that.

Bertrand Le Roy pointed out that there are some frameworks that work with properties but not with public fields. I find this pretty annoying, but this does mean that if you want to use data binding (for example), you'll have to define the properties.

Bjorn Reppen wrote a whole post on his opinion, which I really won't comment on except to say that I'm a firm believer in YAGNI.

Peter Ritchie wrote, "You appear to be contradicting the (framework desgin) Guidelines by suggesting readonly instance fields are a better choice under certain circumstances".

When .NET first came out, there was some talk about writing some general coding guidelines for C#, but we realized that coding guidelines are very specific to teams and can lead to religious discussions, so we opted not to.

Which meant that the only reference we had was the framework design guidelines, which was unfortunate.

The Framework Design Guidelines are great - if you are building a framework. But most people aren't building frameworks - they're building applications, or their building libraries that their group uses directly. In those cases, I think you have to weigh the benefits and the costs.

I think I could have made it clearer that many frameworks fit into the "update this assembly separately" clause.

Finally, there were a couple comments properties being more flexible. My point was that paying for flexibility that you don't need is the wrong place to put your money.