I’ve been using C# for quite a few years now, and have developed a sort of resentment for some of its new features. Mind you, not in the sense that the features are bad, but that they do not go far enough :)

First among these oh-so-promising features is automatic properties. For simple internal types, automatic properties are a great time saver. However, should you need to raise change notifications, restrict assignable values, or get the kind of compiler support that you have with readonly fields, you are simply out of luck (not to mention other property constructs, like dependency properties in WPF).

To be fair, it is hard to imagine how some of those features would fit will into the language (without some kind of meta-language support ;). Really what I’m after is a kind of “shorthand C#”, where you could start with a simple string property Name; declaration (equivalent to the current string Name { get; set; } automatic syntax), then (for example):

• add readonly, so that you could only set its value in the constructor
• or add notify, and it would automatically implement INotifyPropertyChange, and generate a “raise property changed” method (used by the generated property, and available for other use)
• or change it to string dependency property Name = "default";, and have it generate all the DependencyProperty.Register cruft with default value metadata
• or switch from dependency to attached, automatically changing the registration call and replacing the old property-based wrapper with a method-based one

Going one step farther, I could even see adding something like a [GuardNotNull] tag that would add an “if value is null, throw exception” check to a generated property (or, for a WPF dependency property, add a validation callback to do the same, with a partial method for the user to hook). As a developer, I already know how these things should be implemented under the covers; moving to a declarative model just makes things so much cleaner (not to mention reducing the chance for typos or other bugs, which have a habit of creeping into the boilerplate).

These sentiments apply to other areas as well — common interfaces like IDisposable, or IComparable/IEquatable/Equals/GetHashCode; implementing an event with a simple delegate field, a backing collection, or a WPF routed event; creating method overloads; guarding event and method parameters; immutable types; etc, etc.

In fact, I even went so far as to start a little open source project to implement these ideas using code generation :) Being accustomed to computer formats like XML, I saw XAML as a natural way to declare objects like Class and Property that would be used to generate partial classes with all the declared members. Moreover, by using WPF, all of these types could be edited visually using existing designer tools like Cider and Blend.

Unfortunately, I have had to abandon the project for the time being, due to a lack of free time and energy :( I am still quite interested in the project and hope to return to it in the future, though other oh-so-promising code generation tools like StringTemplate may disuade me from my intentions ;) Only time will tell...