Why No Extension Properties?

Why No Extension Properties?

Rate This
  • Comments 35

I'm frequently asked "you guys added extension methods to C# 3, so why not add extension properties as well?" 

Good question.

First, let me talk a bit about C# 3. Clearly the big feature in C# 3 was LINQ. In a sense we had only three features in C# 3:

  • everything necessary for LINQ -- implicitly typed locals, anonymous types, lambda expressions, extension methods, object and collection initializers, query comprehensions, expression trees, improved method type inference
  • partial methods
  • automatically implemented properties

The latter two were tiny compared to the items in that first bucket. On the design side, the syntax and semantics of both features are straightforward. On the implementation side, we already had the mechanisms in place to remove a call site; partial methods and conditional methods are pretty much the same thing behind the scenes. Auto props were also straightforward to analyze and generate code for. The testing burden was not particularly large for these features either.

The C# team was "the long pole" for the 2008 release of Visual Studio and the .NET Framework. By that I mean that if you took the amount of time required to do the work each team signed up for, given our level of staffing, blah blah blah, and made a pole proportionally long for each team in Developer Division, the C# pole would have been the longest pole. Which means that every other team in devdiv had slack in their schedule, but if we slipped our schedule a day, the new VS/CLR would also ship a day late. If any other team slipped a day, well, as long as that didn't make their pole longer than ours, they were still OK. Within the team, dividing up the work amongs the various development team members, the "long pole" work was the lambda binding and method type inference work, which was mine. So in a sense, every day that I was late, we'd slip the whole product that many days. (No pressure!)

Fortunately we have an excellent team here, we all supported each other very well through that release, picked up each other's slack when necessary, and delivered a quality release in plenty of time. My point is simply that unless a feature was either necessary for LINQ, or small and orthogonal and easy to cut if necessary (like the other two), it got cut immediately. There was no way we were going to risk slipping the entire product for any feature that was both complex and unnecessary.

It was of course immediately obvious that the natural companion to extension methods is extension properties. It's less obvious, for some reason, that extension events, extension operators, extension constructors (also known as "the factory pattern"), and so on, are also natural companions. But we didn't even consider designing extension properties for C# 3; we knew that they were not necessary and would add risk to an already-risky schedule for no compelling gain.

So now we come to C# 4.

As I'm fond of pointing out, the answer to every question of the form "why doesn't product X have feature Y?" is the same. It's because in order for a product to have a feature, that feature must be:

  • thought of in the first place
  • desired
  • designed 
  • specified
  • implemented
  • tested
  • documented
  • shipped to customers

You've got to hit every single one of those things, otherwise, no feature. 

When we started working on C# 4, we made a list of every feature request we'd heard of. It had hundreds of features on it. As I described last year, we categorized that list into "gotta have / nice to have / bad idea" buckets. Extension properties were in the "gotta have" bucket. We then looked at our available budget -- which was not so much measured in dollars as in available designers, developers, testers, writers and management multiplied by available time -- and determined that we did not have the resources to do more than about half the things in the "gotta have" bucket. So we cut half that stuff. Extension properties made it past that cut.

We then designed the feature. We had many hours of debate about the proposed syntax on the declaration side, how to call an extension property getter or setter "directly" as a static method, and so on. We came up with a syntax we could agree was acceptable, designed the semantics, wrote up a draft specification, and started writing code and test plans.

By the time the code was in reasonable shape -- not yet seriously tested, but usable and compliant with the spec -- we'd been having meetings with the WPF team. WPF developers were the assumptive primary consumers of extension properties. WPF already has a mechanism that resembles extension properties; it would be nice to unify that mechanism with our mechanism. Unfortunately, after taking a deep look at their real-world scenarios, we came to the disappointing conclusion that we had designed the wrong thing; this was not actually a feature that would solve their problems.

This is, admittedly, in a sense a failure of the design process. In retrospect, we should have gotten input and feedback from the primary customer much earlier. Had we done that then they could have either influenced the design to make something that would work for them, or we could have cut the feature without taking on the expense of writing spec, code and test plans.

But when you're in an unfortunate situation, you've got to decide to stop throwing good money after bad. Rather than take on the additional costs -- testing, documentation, shipping, and then maintenance of the feature for the rest of the life of the language -- in exchange for a feature that did not serve the needs of our customers, we cut the feature. At that point we did not feel confident that we had enough cycles remaining to redesign the feature the right way.

Therefore, sadly, no extension properties in C# 4. Perhaps in a hypothetical future version of C#.

  • Cool - I've actually often found myself wondering lately why there are no extension properties.

    It's a little disappointing, but really nothing to get bent out of shape over.  I don't see why so many people need to complain.  There's nothing you'd be able to do with extension properties that you can't already do with extension methods, except for having a slightly cleaner interface.  Properties ARE methods, fundamentally, they're just syntactic sugar for a getter and setter.

    I'm actually more interested in knowing what was so important for the WPF team (and its customers) that pushed the feature into the "must have" bucket in the first place.

  • From what I gather, the primary benefit of a property over a method is not that you don't have to type (), it's that the designers (such as WPF, windows forms, etc) can bind to properties but not to methods.  It sounds like Eric is saying that due to some as-of-yet unexplained reason, their design did not allow this binding to work as expected.  If it doesn't help with that scenario, then all that's left is the syntactic sugar letting you omit the (), which is not an overly useful language feature and is sure to get in the way of designing a better implementation later.

  • 'In retrospect, we should have gotten input and feedback from the primary customer much earlier...'

    This is starting to sound a bit like Agile ;)

  • @Pavel

    You wrote that an automatic way to do generate property change notifications would be the more interesting feature.  I wrote something to do exactly that, here: http://activesharp.codeplex.com/

    It is usable from standard .NET code, and it works entirely at runtime (no codegen).

  • The problem with automatic property change notifications is when I have a property like this:

    string FullName { get { return FirstName + " " + LastName; } }

    Somehow a change to either FirstName or LastName has to notify subscribers that FullName has also changed. You would have to be able to annotate FullName to indicate what proprties to notify changes for.

  • @Gabe, Actually my SmartData architecture addresses exactly that type of situation. An example (very basic) implementation is on CodePlex [http://smartdata.codeplex.com].  Please feel free to contact me directly for more information: david "dot" corbin "at" dynconcepts "dot" com.

  • In order to be able to set a property in XAML, it has to be an actual property. This means that if I want to be able to write <Foo Spam="eggs"/> then the Foo class has to have a Spam property of type string.

    However, the needs of WPF are more than that. Any given object might have dozens of inherited properties, only a few of which you may care to set, so you don't want to waste tons of storage on all those properties' default values. This means that the property mechanism must support some sort of backing store other than a dedicated field (as automatic properties currently have).

    Additionally, objects may have properties that they don't even know about. For example, the child items of a grid need to have some way of storing what row and column of the grid they belong in. This is accomplished by saying that all UI elements have a Grid.Row and a Grid.Column property. That sort of thing is what I typically would think of as an extension property.

    The types of properties used mostly in WPF objects are DependencyProperties, part of which includes a backing store for only the non-default property values. DependencyProperties also facilitate data binding, styling, animation, and more. Since declaring a DependencyProperty is currently a bit ugly, it would be nice if C# included a mechanism to support it better (hell, even macros would do fine).

    Presumably the WPF team looked at the extension property mechanism they came up with, found that it didn't meet at least one of these needs, and said they couldn't use it. I'd like to know what the mechanism was and how it differed from what WPF needs.

  • Eric, thanks for sharing that story.

    I think everybody would love to have extension properties.

    In my opinion, properties are different members from methods in a sense that they highly need to be discoverable. Databinding is of course almost entirely based on properties and properties metadata, in WPF but also in any other interfaces (winforms, asp.net).

    And if it's been a problem for WPF, I think there are good chance that we all meet the same issues one day.

    Personnaly, I prefer having to wait the best possible feature.

  • It's very saddening to see extension properties meet the axe, I see very little in code that looks dumber than


    but it's nice to see Microsoft be open about the reason for something than sometimes that it feels features get the axe with little to not explanation.

  • Couldn't extensions just be defined when you prefix a variable, method, or property with a class in perentesis?

    (Person) private int height;


    (Person) public Person BestFriend






    (Person) public static void Person(string firstName, string lastName)


    Seems that this would make extensions a lot simpler, (without the extra 'this' parameter) and would make properties and variables extension-able.  Newbie programmer's thoughts; is this confusable with some other C# format?

  • What about STATIC extension methods? It's very interesting there's no mention of it here as it's an oft-requested feature that would be extremely usefull.

  • Eric, We can count on this for 5.0 right?

    I wouldn't if I were you. - Eric

  • With the rising popularity of fluent interfaces (including internally at Microsoft) it seems like extension properties would be more and more useful. From setting "properties" like IsRequired() in the new Entity Framework Code First fluent mappings, to being able to namespace ASP.NET MVC HTML Helpers (for example adding Html.Product.SomeProductRelatedHelper() where Product is an extension property on System.Web.Mvc.HtmlHelper), to the canonical Rubyesque 10.Days.Ago example, it seems like it would fill a missing gap in the language.  Doing some searches it looks like there is a large demand for this, and I for one would love to see it!

  • I would love to see extension properties, if only to pretty my code by getting rid of many brackets (), but understand the reasons why they are not in yet. C# keeps getting better with each version. Good work.

  • BitFlipper does a great job of designing extension properties, constructors, operators, and methods here:


    I propose that design be used in the next version of C#. It requires moving on from the existing implementation, but it's much more natural, and makes the path forward obvious.

Page 2 of 3 (35 items) 123