Why No Extension Properties?

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#.

Comments (35)

  1. Rujith Anand says:

    oh man.. thats so bad.. I was expecting extension properties to be part of next ver of c#…. you will realize the value or importance of it only if you work with extension methods.. in last 6 months atleast 10 times I have thought why these guys(c# guys) didnt include exntesion properties… you ask your WPF team(i was missing it during my databindings) then you will realise its worth more than silly things(for me) like the partial methods.. hopefully you will get a big budget next time :-)

  2. Rick Dailey says:

    I can think of far more uses for extension operators and extension constructors – but maybe that’s just my domain.

    I think the thing that gets me is that not everyone who uses .NET uses WPF.  In fact, I find when I have to put together a desktop app (my primary work is web-based), I use winforms because it’s generally the simplest thing that solves the problem.  However, most of the time, I could care less about WPF (or WF, for that matter).


  3. Pavel Minaev [MSFT] says:

    Frankly, for WPF, some automated way to generate property change notifications and/or propertyinfoof() would result in a much higher productivity increase than extension properties, IMO. So if they are the main potential beneficiaries of this feature, I would hope to see it after those other two rather than before.

    Side note: captchas are still acting weird. When I load a page, I see a new captcha (i.e. it’s different from what was there last time I posted), but when I actually try to enter it when posting, I get the "code was invalid" error message; I have to reload the captcha image itself to get a "valid" one.

  4. TheCPUWizard says:

    @Rick – So you really DO care about WPF and WF [if you COULD care less, you much have a level of caring which could be decreased – it is only if you could NOT care less that you would have no caring]. Just as an FYI, I have adopted the use of WF for almost all of the logic even in Winforms apps, once it becomes "comfortable" there are really some amazing capabilities that can easily be leveraged.

    @Pavel – I agree with you 100%. In fact, I am not sure extension properties really help databinding at all since they are not part of the intrinsic metadata of thye type itself.

  5. Can you elaborate any on the differing needs of WPF vs. the initial implementation?

    My current expectation as a C# programmer is that an extension property "Foo" of type T would be about (nearly? almost exactly?) the same as two extension methods: "T get_Foo(this SomeObject)" and "void set_Foo(this SomeObject, T value)".

    While I can understand the problems with making my "about the same as" statement working with the language, it’s not clear how extension properties would/could be (significantly) different than extension methods.

  6. Rick Dailey says:

    @TheCPUWizard – Yes, I meant "could not care less".  Noticed it after posting, I had hoped that was clear by the context.  Didn’t realize it needed clarification.

    I second J. Daniel Smith’s request for elaboration, it would at least make an interesting article.

  7. Joe White says:

    To me, the natural consumer of extension properties is fluent interfaces. Fluent nHibernate, fluent NUnit, home-grown fluent interfaces, etc. It’s a real pain to have to remember where you do need parens (because it’s an extension method) and when you don’t.

    Here’s hoping it makes the cut in a future version. And I’ll also vote in favor of hearing the details — it definitely would be an interesting article.

  8. I don’t understand how extension properties would be a good idea. Sure, they look cool and may get rid of some parenthesis, but i don’t understand how something that looks like a member types (but it’s actually static) isn’t a bad idea.

    To be fair, I have no idea what extension properties would look like in the mind of the C# team.

  9. Scott Schlesier says:

    This article makes it look as if the only customers that count are internal Microsoft customers.  I expect a lot of developers outside of the WPF team would have been very happy to have extension properties, I know I would.  What about the rest of your customers, especially those who actually pay money for your product?

    Sorry, I must have done a really exceptionally poor job of explaining myself, since you’ve completely and utterly misunderstood me. The WPF team is a few dozen people, tops. We don’t design and implement language features for the convenience of a few dozen people, even if they are very nice people just across the plaza from us. That would be ludicrous. We design features for the WPF team’s hundreds of thousands of customers. You know, the people who pay us money for the WPF designer, and then use it to make applications that they then sell to their customers. The WPF team members are the people who best understand the needs of those thousands of customers; when I say we’re designing a feature “for the WPF team”, it’s not for their internal development team, it’s for their customers. Is that now clear? — Eric

  10. Denis says:

    @Scott Schlesier,

    Could it possibly be taken one step further? I mean could the C# language become – in part, at least – an open-source project where the MS team people do what THEY can from what THEY think is necessary (on the gotta have / nice to have / bad idea basis), and the rest of the community does the rest, if they want it badly enough?

    The users can then purchase the "original" C# with VS/.NET and download the extensions for free, or for a price that looks reasonable from the average developer’s salary (or average small consultancy business’ income) viewpoint…

    Personally, I’ve got enough of ITIL/PRINCE2/SCRUM/etc. certifications to understand what the resource and financial restrictions are all about (and why, therefore, some features not only have to be cut, but also reviled as "not serving the needs of the customers" so that the team doesn’t feel so bad about it :-) ), but one thing I never learned (and never will) is to like and appreciate restrictions (I can tolerate them for now: that’s as much as you gonna get from me).

    I know we can do it now: no one is stopping us, but what I mean is some sort of approval, endorsement, certification, whatever, from Microsoft, saying, basically, "this extension is approved by the C# designers, can be downloaded from MSDN, and is guaranteed to work as well as the rest of the language", to calm down the nervous Nellies from the executive management who want everything legal and official. Would that be possible?

  11. kevin says:

    You mention above  : "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."

    So what happens to the half of the features that were cut for C# 4.0 – do they then become the absolutely must have top 5or 6 things for C# 5.0 ? Or do you again start from scratch for C# 5.0 ?

    Sure , things will change between now and the time for drawing up the spec for C# 5.0 comes around, but keeping the "dropped features from 4.0" as top priority for 5.0 will lend continuity to the process and also help re assure developers that if not in this version then atleast the next.

    great posts , by the way.


  12. Scott Schlesier says:


    What I got from your post was the feature didn’t meet the needs of WPF, but presumably it did address non-WPF needs.  I suspect that there are still many more C# developers out there who are not using WPF than are using WPF.  It seems the non-WPF folks missed out because the WPF team couldn’t use the implementation of extension properties.

    I’m guessing the key is that the extension properties were intended to have been used in most of not all WPF applications, but outside WPF it would merely be an occaisionally used bit of syntactic sugar.


    Mono is already the open source alternative.  Though they have their hands pretty full just keeping up with the core features so far.  Extending libraries is one thing, and I love that MS is embracing OSS more and more.  But, I think getting acceptance for non-standard extensions to the C# language will be very difficult.

  13. Simon Cooper says:

    It would be very interesting to be able to see the list of features that were considered for C#3 in the gotta have/nice to have/bad idea buckets, maybe along with reasoning for a few of them, to see the behind-the-scenes thought processes…

  14. Roman says:

    Thank you. Every time you explain why C# doesn’t do something or does it a certain way, any frustration with the fact quickly evaporates and turns into understanding. This blog always makes me feel better about my most favourite language ever, C#. And I’m wishing MSDN docs linked to your posts whenever possible, because to me, answering the "why"s is no less important than answering the "how"s.

  15. Meta-Knight says:

    Eric, what about static extension methods? What I mean by that is extension methods that can apply to a type like static methods.

    For example, you could have an extension method Yesterday that you could call on DateTime. Obviously, you could create a DateTimeUtil but other coders working on the same project might not now that it exists!

    I know it would have been useful to me in a couple of cases. Has it been considered? If yes, why was it rejected? Could it be added in a future version?

  16. Aaron G says:

    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.

  17. Timothy Bussmann says:

    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.

  18. Awkward Coder says:

    ‘In retrospect, we should have gotten input and feedback from the primary customer much earlier…’

    This is starting to sound a bit like Agile ;)

  19. John Rusk says:


    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).

  20. Gabe says:

    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.

  21. TheCPUWizard says:

    @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.

  22. Gabe says:

    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.

  23. Mitsu says:

    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.

  24. 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.

  25. Ariel Jacobs says:

    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?

  26. mrjimmy says:

    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.

  27. Chris Marisic says:

    Eric, We can count on this for 5.0 right?

    I wouldn't if I were you. – Eric

  28. shawn says:

    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!

  29. Matthew Brand says:

    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.

  30. Chris Moschini says:

    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.

  31. Stephen says:

    With the next release of Visual Studio (2011) and .NET 4.5 in preview, I got to wondering what the status of this feature is.  I know that WPF is kind of deprecated in favor of HTML 5.  But this would be useful in more things than just WPF (and for those not wanting to jump on the HTML 5 bandwagon, it would be great!)

    Any chance the next release of Visual Studio will have a C# 4.5 in it?  Will this feature be in it?

    WPF is not deprecated. We have no plans to do extension properties. The majority of the development work is dedicated to getting asynchrony working and of course all the changes necessary to support a rich WinRT experience in C# and VB. We are not discussing ship vehicles or schedules at this time. — Eric

  32. Avi says:

    Candid! We all do mistakes…

  33. Michael Perrenoud says:

    To all of those who wonder why extension properties aren't just an extension of extension methods let's examine the purpose of a property first.  Properties are meant to store some kind of state in relation to the instance of the object it exists on.  Extension methods store no state on the object itself, rather they simply interrogate the object and add some additional functionality.  They may in fact set values of properties that already exist in the objects definition, but they aren't storing any new dynamic state.

    In contract extension properties would need to store state on that object, dynamically.  Now, if you come from working in dynamic languages this may seem silly to you because you can modify objects and definitions at will, however the .NET framework is not a dynamic framework, it's typed and defined, and security plays a big role in that.

    So, by saying that extension properties are simply an extension of extension methods you are implying that the .NET framework should have the right to simply modify an object's IL at will.  I think that would be a pretty clear violation of security because now the .NET framework would be acting in a malicious manner, abstractly speaking.

    Please remember that Microsoft must solve problems on a different level than what we consume them.  Until they come up with a solution that works well, why don't you use a very basic workaround.  Build a static generic cache object that will store state in a dictionary and then in the extension method get and set against that cache and BAM you have an extension property.

    So, in short (or maybe long) I think you might be able to see why Foo of type T isn't just building get_Foo(T) and set_Foo(T).

  34. Pete says:

    > Properties are meant to store some kind of state in relation to the instance of the object it exists on.

    If you´re referring to setters. But there are lots of cases where you can use getters that return the result of, say, some calcs on the fly not having to access private fields.

    Would have loved to see this feature on C# 5 … :(

  35. George Birbilis says:

    being able to add more constructors via extension methods would save a lot of time to people trying to create for example compatibility layers for porting WPF code to Silverlight (e.g. at ScaleTransform of Silverlight I'm missing a constructor that takes ScaleX and ScaleY params, forcing one to rewrite their WPF code to not pass such params but do set ScaleX/ScaleY explicitly if they want it portable to SL)