The Future Of C#, Part Five


When we’re designing a new version of the language, something we think about a lot is whether the proposed new features “hang together”. Having a consistent “theme” to a release makes it easier for us to prioritize and organize proposals, it makes it easier for our marketing and user education people to effectively communicate with customers, it’s just all-around goodness.

If you look at C# 2.0, it was a bit of a grab-bag. The big features were clustered around the notion of enabling rich, typesafe programming with abstract data types that represent collections of data — and thus generic types and iterator blocks. But there was a whole lot of other stuff in there as well: implementing anonymous methods was a major feature that doesn’t fit well with this theme. And there were other more minor features as well: partial classes, improvements to properties, and so on.

With C# 3.0, the theme was very clear: language-integrated query. Anything that did not directly support LINQ was immediately made lower priority. It is rather amazing to me that partial methods and auto-implemented properties got in at all; that they were relatively easy features to design, implement, test and document was what saved them.

What then is the theme of C# 4.0? Again, it seems like rather a grab-bag: covariance and contravariance, improved interop with dynamic languages, improved interop with legacy COM object models, named and optional parameters. It also seems like a pretty small set of new features compared to generics or query comprehensions.

That was deliberate. Some feedback that we received loud and clear throught the C# 3.0 ship cycle was “this is awesome, we need these language features immediately!” and, somewhat contradictorily, “please stop fundamentally changing the way I think about programming every couple years!” Rather than trying to find some way to yet again radically increase the expressiveness and power of the language, we decided to spend a cycle on making what we already have work better with the other stuff in our programming platform infrastructure.

Now actually works the way you’d expect it to” is not really a theme that gets people excited, but sometimes you’ve got to stop running forward at full speed and take some time to fix the existing stuff that is annoying a lot of people. (When I was on the VSTO team I petitioned the C# team to please, please make ref parameters optional on calls to legacy COM object models, but they were too busy with designing LINQ; I’m delighted that we’ve finally gotten that in.)

We also want to make sure that we are anticipating the problems that people are about to face and mitigate them now. We know that dynamic languages and object models designed with dynamism in mind are becoming increasingly popular. Given that there will be stronger demand for statically typed C# to interoperate with them in the future, let’s get dynamic programming interoperability in there proactively, rather than be reactive about it later.

Looking forward, it’s not clear what exactly the theme of future (hypothetical!) versions of the language will be. The expected onslaught of cheap hardware parallelism looms large in our minds, so that’s a possible theme. Enabling metaprogramming is another possible theme on our minds, thought it is not at all clear how that would happen. (Make C# its own metalanguage? Extend expression trees to statement trees, declaration trees, and so on? Open up the internals of the compiler and provide an object model that lets people generate programs directly? It is hard to say what direction is the right one to go in here.) Fortunately, people way smarter than I am are thinking about these things.

Comments (74)

  1. Marcel Lamothe says:

    What about the immutability stuff you were talking about earlier this year?

  2. Like Marcel, I was hoping for more support of concurrency-safe patterns like immutable types, etc in c# 4. Version 5 likely won’t ship until at least 2012, and by then we’ll all be running on 80 cores and concurrency concerns will not be "looming large" but way overdue.

  3. I was also surprised that there isn’t anything about immutable types in C# 4.0.

  4. Eric Lippert says:

    Well, I have been trying to message that immutability, etc, is (1) important and (2) in our future thinking, not our present thinking. Apologies if I messaged that poorly.

    These things take time. A major factor in the design of work for multi-cores is that there is not a consensus in industry or academia as to what the right thing to do is. With query comprehensions, we at least had twenty years of academic research that we could look at which by and large agreed on the right way to go. With concurrent programming there are as many models as there are researchers it seems. ๐Ÿ™‚

  5. barrkel says:

    I beg to differ on the topic of generics and anonymous delegates being unrelated. That might have been the case in design, but in practice the case is less clear.

    Generics work by restricting the operations available on values of a generic type. When you want to expand on the number of available operations, you need to parameterize by the operation required. And what’s the easiest way to supply operations (i.e. code) by parameters? Anonymous delegates and lambdas.

  6. Jesper says:

    Now that the cat’s out of the bag, and acknowledging that it’s many months out still, periodic updates on the C#-in-C# compiler-as-a-service things Anders mentioned would be an interesting subject. I can’t tell you how often I’ve wanted an official, sponsored full code vocabulary for talking about C# (and with dynamic programming, the cost for trying to make your own or reconcile the existing alternatives rise still). I’m very happy that not just Miguel and part of the Mono team are thinking in these terms but that Anders is involved personally in this as the language designer.

    I’m happy about the C# 4 features although I would have liked more (like readonly automatic properties, an option to ignore out parameters by passing null or actual *class methods* that could be snuck into interfaces the way statics can’t), but between MEF, tuples, PFX and Contracts I’m very well served by the framework improvements.

    I hope everyone working on .NET are taking a second to pat themselves on the back these days. Good work!

  7. Jeremy Gray says:

    @ Eric re: immutability and your comment of "These things take time. A major factor in the design of work for multi-cores is that there is not a consensus in industry or academia as to what the right thing to do is." I’m afraid I have to disagree. If there were to be one and only one very well-agreed-upon piece of consensus in both industry and academia, and that is that regardless of what other open issues there are around parallelism (and I admit there are plenty), it would be that the ability to declare and ensure immutability is an incredibly good thing when making any effort to go parallel, and for a myriad of reasons. And that’s totally ignoring the benefits that immutable types can have even when not trying to go parallel, if only for managing side-effects in order to produce predictable behavior.

    Bringing VB.net features into C# at the expense of features dedicated C# users have long been begging for (eg. non-nullable reference type variables and arguments, immutable types, etc.) is not exactly going to win any favour. Personally, I am trying as hard as I can to be happy with the gift of generic variance goodness, but it is not unlike being a child at Christmas in that it can be hard to enjoy the one good gift you might receive when you look around and all of your other gifts were grandma sweaters. ๐Ÿ˜‰

  8. Patrick Lioi says:

    This is tounge in cheek, but the truth: "*Please* fundamentally change the way I think about programming every couple years!"

  9. Jay Bazuzi says:

    I don’t think that Eric intended this post as "what features do you wish we were adding in C# 4.0?", but I’m not going to pass up the opportunity to

    answer that question anyway. ๐Ÿ™‚

    1. Syntactic sugar for immutable data classes.

    Today, if I want to make a data class, I can either take the easy route (autoprops + no ctor + object initializers), or the safe way (autoprops with private setter + ctor full of tedium + no object initializers allowed), or the very safe way (tedious get-only properties + ‘readonly’ fields + ctor

    full of tedium + no object initializers).  In the very safe way, the property/field name is mentioned 6 times, which violates DRY.

    C# 4.0’s named parameters reduces the need for creating multiple ctors, but the ctor is still as tedious to write as before.  It also makes the "safe" and "very safe" models nicer at the call site.  But I don’t see anything that makes the *implementation* any nicer, so I still have to decide between easy and safe.  A language change could create a "pit of success", where creating immutable data types is easy, too.  (See, I said "pit of success", so now Rico will make you do it.)

    2. The ability to refer to ‘this’ in field initializers.  

    I often refactor a larger class in to several smaller classes, where each one exists as a field with a specific responsibility but needs to find its way back to the main object.  As the language is defined today, I have to initialize these fields in a ctor, while other fields get initialized in field initializers, making my code inconsistent and bug-prone.  There are also a few patterns for converting enums to objects that are either awkward or impossible because of this language limitation, but would be great for code structure otherwise.

    In both cases, it seems like a few very small changes to the language would be a big benefit, at least to me.

    Eric, if you want to understand more about my thinking, drop me a mail.

  10. Lars says:

    Just keep to the list and everything will finally be as great as it once was ๐Ÿ™‚

    http://www.paulgraham.com/diff.html

  11. jQuery/ASP.NET/ASP.NET AJAX/ASP.NET MVC Visual Studio patched for better jQuery IntelliSense . Yes! Steven

  12. RichB says:

    > "Now actually works the way you’d expect it to" is not really a theme that gets people excited, but

    > sometimes you’ve got to stop running forward at full speed and take some time to fix the existing stuff

    > that is annoying a lot of people.

    Great – so I can now call a base class method from an iterator/anonymous method in a derived class? You can’t have ‘fix things’ as a theme unless you fix this glaring inconsistency.

  13. Aside the parallelism/mutability theme, which will be important anyway, another good theme for C#5 could be System.Diagnostics.Contract syntax support at language level.

  14. Tanveer Badar says:

    If I had 100 bucks to spend on various features coming in 4.0+, I would add 10 of my own and put the bet on metaprogrammability.

  15. Eric Lippert says:

    Re: calling base methods from anonymous methods: Yes, we fixed that.

  16. int19h says:

    Given that BCL guys are introducing DbC ("code contracts") in .NET 4.0, at the library/instrumentation level for now, it would seem logical to me to extend this to full-fledged support on language level (the library-only solution can be rather quirky syntactically – just look at the pains one has to go to write a contract for an interfaec).

  17. Ian Marteens says:

    <i>2. The ability to refer to ‘this’ in field initializers.  </i>

    That would be very dangerous, as you need to take evaluation order into account. As a matter of fact, I even doubt CLR would admit it… at least, if you implement it as "normal" field initialization (I mean, before calling a base constructor).

    Instead, I should provide fileld-like initialization for automatic properties.

  18. Igor says:

    Eric, if you are looking for ideas how to enable metaprogramming in C#, you should look at Nemerle where it is already done. See the following links – http://nemerle.org  and http://nemerle.org/Macros

    For example, Nemerle does not have if-else statement, but it defines it as a macro using quotation operator <[ โ€ฆ ]>

    macro @if (cond, e1, e2)

    syntax ("if", "(", cond, ")", e1, Optional (";"), "else", e2)

    {

     <[

       match ($cond) {

         | true => $e1

         | _ => $e2

       }

     ]>

    }

  19. yumi says:

    You need to take a look at Nemerle language (nemerle.org) for .Net. It’s something like

    superset of C# language with minimal core. All other features like foreach, if then else etc

    made with macro-system. Its something like right Lisp for .Net ๐Ÿ™‚ This language now actively

    supported by RSDN community. I hope that you fill find new fresh ideas about how to add

    metaprogramming at C#.

  20. ggreig says:

    While I’m sure that a meta-programming solution specifically designed for the purpose could be "better" than C++ templates, I would hope that the design would be such that it would be possible to transfer some of the years of community and personal experience from C++ into C#, given the relatively close relationship of the languages.

  21. Jon Skeet says:

    I’d just like to add to Jesper’s plea (and Jay’s, indirectly) – readonly autoprops would be a significant win from my point of view, *and* give us at least an *easier* route to immutability. I can’t see that it would be very hard, either – although I’m aware that what seems simple often isn’t, and *any* change requires design work, etc.

    Basically I’d just like to extend automatic properties such that:

    public string Foo { get; readonly set; }

    expanded to:

    private readonly string <>_Foo;

    public string Foo { get { return <>_Foo; } }

    and any assignments to the property within the constructor (the only place they’d be legal) were transformed into assignments to the variable.

    That, combined with the named parameters of C# 4 would make creating immutable types a lot easier. I’m happy to wait for really good support of immutability complete with a declarative syntax and compile-time checking – just help us this one little bit ๐Ÿ™‚

    (I suspect C# 4 is too locked down to allow anything new in at this point, but if there’s the slightest chance of getting readonly autoprops, I’m happy to campaign hard for them ๐Ÿ™‚

  22. stefan.wenig@rubicon-it.com says:

    Jon,

    agreed, but there’s more: one of the useful feature combination for C#3 was the ability to create simple classes with automatic properties only, without special constructors only using object initializer syntax for instantiation. Now can we have object initializers for immutable objects too, please? I know I’m borderlining the impossible here, because object initializers are just property assignments _after_ the default ctor has been executed. (But in case of a generated default constructor, would that make any difference? OK, maybe it would, because the class might have base classes, and depending on their being auto-generated would be a mess.) But still, getting object initializer syntax for immutable objects would do a lot to reduce code for trivial types _and_ promote immutability.

    How bad would it be to have "readonly" in automatic properties mean "write only via initializers, ctors or object initializers"?

    In some cases this might result in bad things, but how important is it to support the concise automatic property syntax with the proposed readonly extension for those cases? shouldn’t simple things be simple, and hard ones merely possible?

    But then again, this might be too surprising for average C# users who don’t make it their hobby to study language specs. Just an idea, not thought through.

    Stefan

  23. Jon Skeet says:

    stefan: With optional and named parameters, you can get object initializer *style* instantiation just with a constructor. The nice thing about object initializers is that they’re just translated into standard property accesses – it’s pure syntactic sugar. When you break that connection, it becomes tricky.

    I have other suggestions around immutability and object initializers, using builder objects, but that’s a different matter (and Eric’s already got that suggestion somewhere in his inbox – I’m neither expecting nor requesting any movement on that front).

    I’m hoping that the less we ask for, the more likely we are to get it ๐Ÿ™‚

  24. stefan.wenig@rubicon-it.com says:

    John: you’re right, you can get the syntax, but if you include the class definition into the calculation, it won’t be nearly as concise. Declaring an immutable class with n properties in n+1 lines (not counting curly braces) would be just great. Yes, this might still be a bad idea in the end, but without seriously discussing it we will never know. I did not ask for it though, it’s just an idea.

  25. Thomas Eyde says:

    I wonder when

    var c = Click;

    if (c != null) c(this, EventArgs.Empty);

    will be fixed.

  26. Eric Lippert says:

    You haven’t said what’s broken.

  27. Jay Bazuzi says:

    To make my life simpler, I initialize my events like this:

       event EventHandler Click = delegate {};

    Now I don’t have to worry about null checks & temporary local copies.  Just

      Click(this, EventArgs.Empty);

  28. Asad Siddiqi says:

    *Please* Dont change the way everything works every year. .Net 1.1 to .Net 2.0 was absolutely OK since the basics were almost the same and it was a smooth transition. .Net to .Net 3.0 is a bit painful for the small scale windows applications developer (Based on WPF and not on windows forms) Yeah I know there is a whole lot more functionality to it and its very very powerful , so OK.

    But please dont change the internal architecture every year, everytiume you do that you looses developers and it is hard to keep up with all the technologies.

    I think including specialized development tools for targetted developers would be a better idea than to change the architecture totally. I am a fan of microsoft development tools and have been using them since 6 years and I only have admiration for them which started with VC++ 5 to .Net 3.5 .

    But I do realize now that things are moving way to fast and my concepts are shaken up REALLY SHAKEN UP with every new release. Things are not the way they used to be !! I think we really need to stabilize a bit + have the support for previous architectures as well (As we dont get the chance to develope with the latest all the time due to client restrictions , hardware restrictions e.t.c. )

    I hope I was able to present my point of view !! I really love development and Microsoft but doesnt want C# to become "Ruby on Rails" . So please dont take all the code away and leave it to configurations, configuring is a whole new language for the developer which is difficult to understand without the underlying architecture which is changing all the time.

  29. Thomas Eyde says:

    @Jay: Nice hack. I’ve forgotten that one.

    @Erik: The whole observer pattern is broken. The whole point with this pattern is to broadcast information to anyone interested, without knowing how many they are.

    The way events are implemented we have to resort to hacks, as Jay suggests, or we have to check if anyone is really there.

    The much needed null check proves the abstraction is leaky. The need for a temporary variable proves it’s not safe.

    All the repetitive code we have to write should have been done by the framework.

  30. Mark Rendle says:

    @Asad: very few of the changes to C# and the BCL are breaking changes. There’s no rule that says you have to use WPF, or LINQ, or any of the (incredibly cool) new things that have been added over the last 7 years. And you can pick and choose the ones you do use; my project is still on Windows Forms but makes extensive use of LINQ.

    The fact of the matter is that the software development world is moving very fast at the moment, and C#, as a leading citizen of that world, is obliged to at least try and keep up. Hence the dynamic support in C# 4.0, PFX and Contracts in .NET 4.0, and meta-programming coming in a later C#.

    Personally, I’ve found that the new models, patterns and capabilities in each version of C# have made me a better programmer by changing the way I think about the way my code.

    As the saying goes, it’s better to have something and not need it than to need something and not have it.

  31. VladD2 says:

    About last section (about metaprogramming)…

    Eric, excuse me, you ignore two question about Nemerle.

    You can say, you know this language?

    You try to install it (http://nemerle.org/Download#CTP_packages)?

    What you think about metasystem of this language?

  32. int19h says:

    > But I do realize now that things are moving way to fast and my concepts are shaken up REALLY SHAKEN UP with every new release. Things are not the way they used to be !! I think we really need to stabilize a bit + have the support for previous architectures as well

    My impression so far for .NET 4.0 & C# 4.0 is that it is largely what is going on. It is certainly less "revolutionary" than .NET 3.5 (+SP1) / C# 3.0 – more incremental changes, more cleanups, reintegration of currently separate components into the base framework (DLR, PLINQ etc) and so on.

  33. Kor Nielsen says:

    Another vote for immutability syntactic sugar…even if that were the only new feature in c# 4.0, I would be very happy.

  34. Néstor Sánchez says:

    My vote too for an immutability feature for C# 4.0.

    Also, I would like to have that "Eval" method shown in the PDC (and not wait until 2012 as suggested by Miguel de Icaza suggested while shown the same (?) in Mono)

  35. Marcel Popescu says:

    Jon, what’s wrong with

    public int Something { get; private set; }

    as far as readonly properties go? The fact that you can assign them in methods of this object? (As in, make sure I don’t do something stupid with this property?)

  36. int19h says:

    Marcel, it’s both that and the fact that there’s no inline initializer for autoproperties.

  37. Jon Skeet says:

    Marcel:

    1) It’s not readonly within the class itself – so you have to make sure you’re not stupid.

    2) As int19h said, it would also be nice to be able to provide a default value, although that’s not quite as big an issue for me.

    3) It’s just not immutable then – anything that checks for immutability would either fail on a type with these properties, or have to check to see that the setter really was only called during the constructor.

    4) It can’t be a readonly field in the IL while it’s got a setter. This may mean the CLR can’t make certain optimisations.

    5) It doesn’t show intent – I will quite often have a public getter and a private setter for things which I genuinely want to be mutable via other properties/methods. It should be obvious from the code that this is a different matter – that it’s a genuinely readonly property which will be set in the constructor and then never touched again.

  38. int19h says:

    Immutability is certainly part of the contract  (something that C++ "const" misses, by the way) – it’s  the distinction between "you can’t change it, but it might change by itself (or by someone else)" and "it can’t be changed by anyone, period". At the moment, it’s implicit in the code, and you have to explicitly state in the documentation that your type (or a particular property) is really, truly immutable. For fields, that’s what "readonly" does (with some caveats, such as "… after constructor runs"). It’s just strange that there’s no equivalent for properties and classes as a whole.

    Note also that there is a distinction between "all properties are immutable" and "type as a whole is immutable". This has to do with versioning – if I write a method that returns a reference to my object, which I think is immutable, because all its properties are immutable (but its author thinks otherwise), I might be unpleasantly surprised if, in the next version of that object, it suddenly gets some read/write properties, and my callers will be able to change my internal state!

  39. Halo_Four says:

    I really wish that Microsoft would pull a few more language enhancements from the Microsoft Research Cฯ‰ (C-Omega) project, particularly the concurrency abstractions based on join calculus.  In my opinion those language enhancements represent the most elegant solution to many complex concurrency situations.

    http://research.microsoft.com/comega/

    Asynchronous Methods:

    public async DoSomeWork() { }  // async methods automatically execute within another thread

    Joins/Chords:

    public async Put(int y);  // at least one async method without a body that acts as a signal queue

    public int Get() & Put(int y) { return y; } // a normal method combined with one or more async methods.  Calls to Get require a corresponding call to Put and will block until/unless such a call is queued.  The parameters from both methods are available in the method body

    I would also like to see support for explicitly declaring an anonymous type:

    List<struct { int i; string s; }> list = Enumerable.Range(1, 10).Select(val => new struct { int i; string s; } { val, val.ToString() };

    I would like to see the ability to define mutable members of an anonymous type, which VB.NET already supports:

    var person = new { ID = 1, ref Name = "Bill Gates" };  // Name is a mutable member and is not used when calculating GetHashCode or evaluating equality.

    I would like to see syntax to define an anonymous delegate type, even if it just maps to the corresponding Func<> or Action<> delegate:

    int(int,int) add = (x, y) => x + y;

    I think some of the tuple functionality from Cฯ‰ would be useful.  I know that .NET 4.0 is due to get official tuple type support that is to be shared between languages (including F#) so perhaps this functionality could be considered?

    var item = new { x = 5, y = "Hello", z = new { a = 42; b = new Button() } };

    foreach(int number in item.int::*) { … }  // selects all of the int members from the anonymous type, 5 and 42

    The Cฯ‰ project was an excellent project from which quite a few C# features were derived.  I think it still contains a few useful treasures that would benefit us.

  40. Mike Adkins says:

    Assad – I agree with you completely.

    Mark Rendle – You’re right also – we are not required to use new technologies like LINQ or WPF. The problem is that as developers we know that there is probably a good chance that these new developments will reduce coding time and offer new features in the long run but we don’t know if they are ready for prime time yet.

    I find myself doing a couple of things whenever a new technology like LINQ is made available,

    #1. Does this technology do everything that I can currently with System.Data classes?

    #2. Learn the technology.

    To me No. 1 takes as long as No. 2. It would be nice if whenver a new technology (or syntax change) were incorporated, we didn’t have to spend so much time figuring out if it was so much better than currently available stuff. Kind of like the reviews you read on NewEgg when purchasing hardware. The MS development team guys should just come right out and say "YES" or "NO" you need to switch to a new particular methodology. I should be able to go to the main page for LINQ and read the review which says "LINQ is the way to go right now." or "LINQ is great but you probably shouldn’t port everything to LINQ just yet because it lacks support for…".

    In the end however, I do appreciate the effort the gang at MS and on the blogs is putting into moving forward. It’s just seems to get harder to keep up as I get older.

  41. Fred Derf says:

    How about "fixing" what once was the promise of dot net: program once, deploy many – in other words, a CLR for MacOS.

  42. Ted says:

    Releasing a .NET/C# combintation that replaces 90% of all win32 api calls.  This is within striking distance given that many win32 based technologies are at  or near end of life (e.g., com) and could be replaced with a .NET to win32 api thunk layer.  

    SQL Server is a model for this since the’ve rewritten SQL Server 4.2 (sybase 4.9) from scratch over the SQL Server 7, 8 and 9 releases).  MS should be able to do this for large chunks of the win32 api call with the next few service packs to Vista and Server 2008.

  43. jemiller says:

    This isn’t really a language issue, but, since some people brought up concurrency, I would like to see classes like ObservableCollection<T> improved so that they can be used from multiple threads. i.e. you should be able add items to an ObservableCollection on a background thread and have it update the UI/WPF automatically.

  44. Wes says:

    Why not just use snippets for some of the complaints about immutability?  It’s pretty easy to make a readonly property snippet.  I’d then use a code generator myself for all the constructor magic & partial classes, but that’s only if I understand the problem correctly.

  45. shawn says:

    I would rather see a release of c# that integrates with SQL Server and Windows in a way that’s supports and shares the same view for things like datatypes and hardware devices; through a standard api for stuff like sound and video processing.

    We need api’s for multi-touch, speech/sound/video processing, webcam devices etc etc

    WPF and Dynamic syntax is great and all, but adding new stuff is not always what is needed.

    We need better support for things that already exist but are only accessible via criptic Win DLL’s and RegEdit settings (or not at all)!!!

  46. Ionel Munoz says:

    I would like to be able to do the following with generics:

    class A<T> : T

    {

    }

    In C++ you can do that. In this way you can "decorate" the type T with extended functionnality that can be reused, and still being a T + A.

  47. Reynard says:

    does this means that it is easier to do complex marshalling?

  48. SEO Elite says:

    Thanks for the informative article

  49. DevExec says:

    C# is a fantastic language and my congradulations to the entire team!

    Moving forward it would be nice to cleanly define types for variables for their specific purpose…

    declare Int32 Index; Index a = 5, b = 6; Int32 c = a; // throws invalid cast exception for a to c

    Perhaps LINQ also needs to be editable at run-time without requring recompile. This is the main reason I don’t use it in development.

  50. °(n.n)° says:

    Well, what I really like from python is tuples, it’s a nice way to store data without the tediously need of creating a class or struct just for getting the job done. It’d be great if c# could have a similar implementation, especially now it has strong support with dynamics.

    Well, guess this is just another item for the wish list…

  51. Vijendra.1007 says:

    Hi,

    One new feature which can be implemented is to provide [Encryption] attribute on Class, Methods, Assembly, Namespaces so that the class over which [Encryption] attributre is applied get encrypted. So that no disassembler should be able to view the class. the Decryption algorithm should be kept with CLR which only can decrypt the [encrypted] class at run time.

    The so called LINQ, Var feature is not getting used in any company. People dont use this in their application, except for some rare occasion.

    Microsoft should provide value features.

    They are not providing the feature that can help developer to code fast and easily.

  52. Masum says:

    Microsoft should provide more example soruce code with new release.

  53. Jeff Lewis says:

    "please stop fundamentally changing the way I think about programming every couple years"

    I’m going to up this a bit… and move outside of C# for a moment.

    Consider what happened with Windows Apps, Windows Forms and then Windows Presentation Foundation.

    Each was an improvement over the previous in terms of functionality – but only one was a simplification in implementation (guess which one? ๐Ÿ™‚

    Coming back to C#, WPF broke the Forms model and I’m still not convinced for the better. It’s not easier to use. It’s not elegant. It’s so difficult to design around that even in VS2008, you find yourself typing in a lot of the UI elements by hand. You can use Blend – but now you have to buy a whole separate application to design parts of your app – and it’s a design tool that’s so different from the prexisting model that basic things that are easy to do in VS2008 directly (like – binding a database table to a data grid in a form) are bewilderingly complicated and require many levels of obscure indirection.

    WPF ‘introduced’ the notion of attribute manipulation and did it in a very clumsy, non-obvious way. Which was odd because C# and .Net already HAS attributes and a fairly clean and elegant way to manipulate them. WPF broke the very elegant properties model and brought back explicit set/get methods.

    Going back to your the original statement: there are ways to improve and add ‘essential’ features (but please, there’s essential and then there’s ESSENTIAL) without throwing everything out the window and starting over.

    What’s needed is a feature referee who vets implementation models for new features. A continuity cop (to borrow a term from the comics industry) who reviews new features and how they’re to be implemented and looks at the new feature in context of the entire picture and only lets wildly new features in if there really is no other way to fit it into the existing paradigm.

    I think most of us can handle gradual changes and big but isolated changes – LINQ is a good example – if you don’t like it – you can stay with typed datasets and table adaptors. But if the only way to get access to animation is to have to completely turn your application on its head and graft in ugly things like XAML…

    Well, people will complain.

  54. SkyBeaver says:

    I am becoming increasingly alarmed at the pace of changes to the C# language.  Many of them seem to be made without a clear business justification.  

    "Because Java has it" is not a business justification for a feature.  For that matter,

    neither is "because Java doesn’t have it".

    I finished my CS graduate work in 1987 and entered industry writing UNIX-based database code in C and C++.  At the time, IBM’s application development frameworks dominated business computing, and yet were an insane mish-mash of partially-interoperable pieces.  The lack of clarity in IBM’s vision — it made sense to them but hardly anyone else

    — is what made them vulnerable.

    In contrast, C, C++, UNIX, and later Windows offered refreshing clarity.  IBM’s crazy quilt of aplication

    technologies quickly went from dominant to a historical footnote.  They got clobbered because

    their excessively complex vision made sense only inside their own company walls.

    Another example of a too-clever-by-half language from around that time was Ada, which again C# is beginning to resemble.  It was a patchwork quilt of features that a committee of academians and

    "O-O Hezbollah" types all thought the world needed.

    I am beginning to see a lot of similarities between Microsoft in 2008 and IBM in 1987.  I

    urge the language team to slow down, take a deep breath, and think about the C# platform

    in terms of simplicity, consistency, and coherence.  Leave the boutique language features

    to the boutique languages.  

    There is a reason that we’re all not programming in Ada today.  As Jerry Seinfeld once said, "the

    road less travelled … is less travelled for a reason".

  55. Néstor Sánchez says:

    I am becoming increasingly alarmed at the comments about slow down the good paced evolution of the C# language by some guys saying "i cannot go so fast, so slow down everybody". And I say "good paced" considering the need to -right now- take advantage of the emerging technologies (i.e. multi-core, multi-touch, cloud computing).

    Right a few weeks ago, I was required for develop a web application for project management (you know… tasks, schedules, time consumption, people and other resources) and was fortunate to have Silverlight 2, C#, XAML, LINQ, etc. for concluding with a very good product and on schedule.

    I think the complains about delivering frequently (in a subjective timescale) new versions of C#, tools or other techs are related to a problem of management of certain (I don’t even believe the most of) companies. They should invest on training their developers, and the learning curve will be compensated by the productivity gain.

    So…  welcome the innovations on the 18 months dev cycle.

  56. I’d like to see support for a ThisType in Generics.  Being able to create a factory method in my class that returns an object of that type is something that comes up on a regular basis, and it would be nice if there was a way of being able to avoid having every subclass specify its own type.  It would also make the Singleton pattern simpler to code.

  57. K Ray says:

    Through my many years of programming I have concluded that it is important to use the right language for the job.  For example… when speed is critical, C or Assembly is preferred.  Lisp is good choice for computer generated code.  … and the list goes on.  One of the fundamental beauties of Visual Stuido is the ability to program and combine many languages into one application.  

    There is an old saying… Too many hands in the pot will spoil the stew.  C# is a great language as it is today.  Trying to make it the only language in the world by adding every possible language feature that any developer would ever need is going to… spoil the stew.  

    I think that MS should focus more on making language integration easier rather than trying to shoe-horn everything into one language.  After all… all languages end up running on the same machine and in the case of Visual Studio, running through the same compiler.  Why can’t they all ‘just get along’?

  58. Edgar says:

    I would love to see C# better address Concurent programming.

  59. jyr says:

    I would like to see more improvements on metaprogramming

    Consider this code, how to get rid of the duplication?

    namespace Utils

    {

    public static class Utils

    {

    public static Action UICtx(this Control control, Action func)

    {

    return delegate()

    {

    if (control.InvokeRequired)

    control.Invoke(func);

    else

    func();

    };

    }

    public static Action<T> UICtx<T>(this Control control, Action<T> func)

    {

    return delegate(T a)

    {

    if (control.InvokeRequired)

    control.Invoke(func, new object[] { a });

    else

    func(a);

    };

    }

    public static Action<T1, T2> UICtx<T1, T2>(this Control control, Action<T1, T2> func)

    {

    return delegate(T1 a1, T2 a2)

    {

    if (control.InvokeRequired)

    control.Invoke(func, new object[] { a1, a2 });

    else

    func(a1, a2);

    };

    }

    public static Action<T1, T2, T3> UICtx<T1, T2, T3>(this Control control, Action<T1, T2, T3> func)

    {

    return delegate(T1 a1, T2 a2, T3 a3)

    {

    if (control.InvokeRequired)

    control.Invoke(func, new object[] { a1, a2, a3 });

    else

    func(a1, a2, a3);

    };

    }

    }

  60. GuyO says:

    How about finally providing and overrideable assignment operator….

    immagine a vector that represents a physical quantity — mass, length, time, charge

    a speed would be represent by 0,1,-1,0     => length / time

    the arithmetic operators could be overriden such that a division of a speed vector 0,1,-1,0 by a time vector 0,0,1,0 would result in an acceleration 0,1,-2,0  => length/ time^2

    this can all be done now except for the dimensional checks made during the assignment — there’s current no way to insure that the result of a speed / time computation is assigned to an acceleration….

    you could even get really slick and check atrributes to insure the the correct MKS, meters kilograms, seconds and CGS centimerters, grams seconds checks were made  ( attributes work fine here).

  61. Joe Reddy says:

    I know Microsoft likes to go for the grand and the exciting, but how about more practical stuff?

    I don’t have the largest developers circle, but I know of absolutely no one in a circle of 50 or so who uses LINQ, or cares about binding to anything on a user interface, etc.

    How about something as simple as an optional compiler warning telling me when an argument is not being used in a method, or if the value returned by a method (function) does not have a variable assigned, etc.

    And ditto what Sky Beaver said.

  62. Brian Womack, PhD says:

    I’d REALLY like to see support for generic classes and operators as first class entities.  To see what I mean, try to write a generic class for Matrices that support all operators you might want to overload: +, -, *, /, ^.  This is not allowed in C# 3.0.  You end up creating two copies of the class for float and double.

    I believe this can be done with a ‘where’ clause in the class declaration that lets you list the types supported:  i.e. where T is float, double, int, long, uint, ulong.

  63. Svavar says:

    I’d like to put my vote in for parallelism (however it’s implemented).

    Quad core processors will be ubiquitous in the next 12 months (if not sooner) and dual-quad as well as 6 & 8 core processors are just around the corner so I’d say parallelism is already here.

  64. Thomas says:

    I love the extensions for 3.0, I hope the extensions for 4.0 get just as good!

    @other Thomas  & Jay. In C# 3.0 this can be done very nicely like so:

    Extension method

    public static class EventStuff

    {

           public static void Raise(this EventHandler handler, object sender, EventArgs args)

           { if (handler != null) handler(sender, args); }

           //and others

    }

    and call your events like this

    {

           public event EventHandler MyEvent;

           protected virtual void OnMyEvent(EventArgs args)

           { MyEvent.Raise(this, args); }

    }

    In this way you don’t waste memory and CPU time.

    Personaly I’d realy like a non-nullable reference type. Something like:

    object! x = null; //generates an exception

    And an extended coalesce operator. possibly:

    int x = a.b.c.d.e !! 0 ; //x would become 0 if any of a, b, c, d or e would be null.

    Treat lambda’s, delegates and methods like values properly.

    So that their hash values don’t only depend on the signature and delegates generated with the

    same code tree can be sensibly compared for equality.

  65. Reineir Post says:

    GuyO: nooo! Now I can read assignments and understand what they mean without having to be familiar with the classes involved.  Please, C#, keep it that way.

  66. Interesting article, Eric.

    Finding the happy medium between sweeping change and stagnation is a consideration that we are all faced with as developers regardless of who our target audience is.  I found it surprising to hear just the extent of this issue as it relates to further C# development given the relatively advanced target audience that your team has.  It prompted me to share some of my own thoughts and perspective on the topic as someone whose target audience is often not even computer literate: http://icrontic.com/forum/blog.php?b=115

    Regards,

    Rob

  67. Nick says:

    Virtual Constructors would be real nice.

    Pity Anders didnt bring this concept in from Delphi.

  68. Lee Grissom says:

    To build on top of what Nick said, "Virtual Class Methods" would solve a few problems that I’ve had over the years with C#.  I could then do virtual static classes.  Anders Hejlsberg designed this capability into Delphi, so I’m curious as to why it has been omitted from C# for so long.

  69. Peter Herschel says:

    Disposal

    I’d love to see the need for directly calling Dispose() go away. So much code plumbing code in such an advanced language!   There must be away to improve this whole issue.  Maybe Dispose could be called automaticlly.

    That’s what the “using” statement is for — Eric 

    Object Oriented

    I’d love to see improvements in the language that help limit scope.  Example: class fields that are used to serve up properties.

    How is that different from auto props? — Eric

    Deterministic Lifetimes

    A language feature to add to a class?  Is there a role in C# for this concept and still maintain performance.

    That’s what the “using” statement is for — Eric 

    Revisit Existing Features

    There is a tendacy to forget about features that were released in previous version. These are often the basis for much of the languages use:

    * SqlClient
    * Forms
    * Click Once
    * Crsytal Reports

    These would greatly benifit from some updating.

    Sure. But none of those are language features. — Eric

    -Pete

  70. mastermemorex says:

    A scope about the popularity of different programming languages can be found here:

    http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

    In my opinion that improvemets, although interested,  unlikely sky rocks today’s low popularity of C#.  I would like to change "please stop fundamentally changing the way I think about programming every couple years!" for "please stop telling me what you think is the best way of programming and give me a language for programming the way I would like". In my opinion, any improvement that is not stick with the best performance is not worthly enough.

    I would like to see solved "the struct pointer juju problem"

       static void Foo<T>(T value) where T is struct

       {

           uint size = sizeof(T); //Error 1. Cannot take the address of, get the sizeofโ€ฆ

       }

    This is a basic and large demanded feature that of the language. Also some level of inheritation of fields for structures would be a huge improvement of the language.

  71. Alan says:

    We are witnessing a machine processing performance explosion in action today and over the next few years it is set to accelerate – increasing core count, Larabbee etc are prime examples.    The days of boost via GHz uplift are gone.    One (not the only one I grant you) of the historic arguments for C and C++ over C# and other CLR based languages has always been their efficiency.   For many classes of applications this advantage is likely to shift more from code level efficiency to who can best implement optimisation at the higher level – i.e. Parallelism.    In future, performance optimisation effort in developing our applications may possibly be best spent at this level and it will need best of breed support to do so.    

    At a lower level, for some classes of application the parallelism boost will also come from  wide vector SIMD processing – 128 bits on today’s CPUs and 512 bits on Larrabee I’m lead to believe – and how long before it is made wider on mainstream CPUs?    This is currently completely ignored by the CLR targeting languages including the CLR version of C++ – why?  

    The battle ground for future Applications winning or losing may well be fought over who best leverages these increasingly accelerating processing resources.     I actually like what some have described as the "boutique"  C# language changes, but I am also fearful for C#’s future – if it cannot provide ease and reliable leveraging of the huge processing potential, then C# apps will fail to compete in both the applications generated from it and C# will fail in its battle with the other languages.

    My customers do not care if my staff are using Linq under the bonnet to talk to the database or internal data or not, or using the latest Generic Constructs, or more elegantly implemented patterns.    They will care when my competitors reliably bring out a 5, 10 or 20  (in 10 years?)… times performance boost.    I have always liked C# as a developer and C# for its productivity as a company owner,  and I have always hated the fact that it always plays second fiddle to C and C++ for crunching power and perceived performance.

    I appreciate the new "Parallel For" etc, but the C# team (and CLR and VS team) need to continue to heavily invest effort in parallel processing leverage (coding, debugging, parallel processing run time analysis etc) and although I appreciate that C# (and CLR) have some of its roots in the "safe programming" and metal independent paradigm, I would really like to see it recognise the blossoming SIMD capabilities of the hardware.    

    Let’s put on hold for a little while some of the more " boutique" or "ivory tower" language changes and really arm C# with the weapons for the performance battle that is coming.

  72. Bryan says:

    @mastermemorex: you can do this:

    static void Foo<T>(T value) where T is struct

      {

          int size = Marshal.SizeOf(value);

          // or Marshal.SizeOf(typeof(T));

      }

  73. ShuggyCoUk says:

    * non nullable types backed into the language would be the biggest win for me. (I would favour a compiler switch to move a project to not nullable by default and then allow the ! syntax (or ? for consistency with Nullable, albeit perhaps with confusion so ambivalent there) for nullable parameters and variables.

    * After than enum constraint (though Jon’s unconstrained melody might work around that for quite a few scenarios)

    * generic constraints on static operators will full JIT optimization down to specific instructions for native types

  74. Carsten says:

    I know I may be a little late, but anyway…

    Eric: Well, life's not a bed of roses. And then some. Let's assume this discussion went into a wonderwall… ๐Ÿ˜‰

    1st — AOP. Please, Microsoft, buy Gael Fraiteur's company, and integrate the stuff into .NET!

    2nd — Attributes evaluated at runtime, like attributes whose params are Lambdas that refer to actual code, or to extension methods

    3rd — Integration of the Rx into the .NET core

    4th — Attributes, like in 2nd, for getters and setters (separate)

    Why am I suggesting these?

    With AOP, you could fulfill a whole lot of the proposals made before. With at-runtime-evaluated attributes, you are close to a solution for immutables (or at least thread-safes), and with the 3rd and 4th, you'd kill the nasty fly.

    Whatever the syntax could look like, you'd get:

    * Less reflection in code, because arbitrary attributes/aspects would be evaluated at runtime (e.g. by the MEF, without explicitly coded strategies and lookalikes).

    * Metaprogramming via attributes/aspects

    * Immutability via attributes/aspects (OnEnterSetLockAttribute(), OnLeaveReleaseLockAttribute(), FinallyReleaseLockAttribute() and so on)

    * A kind-of native coupling between the event subsystem and the Rx

    In my spare time, I am working on a distributed, self-coordinating microkernel (the "Disco-Mike") devoted to creating EBCs (event-based components), and I am feeling a lot of pain with all the reflection stuff. If PostSharp was still free, I'd not even suffer from a tenth of the pain. If the Rx would integrate smoother, I'd not even suffer from a tenth of the pain. If there were at-runtime-evaluated attributes, there would be no need for at least 30% of my code, or even more. If there were attributes for getters and setters, separately, the Observer Pattern would be like "batteries included".

    EBA (event-based architecture) and first of all DEBA (distributed …) is, imho, the very way to a "zero-coupled" world in which contracts could base on a single notation, itself basing on XSD and WSDL (and maybe on a successor of SCA). This would in turn make interfaces themselves obsolete.

    Just another step of abstraction. Just another step of less coupling.

    Just not only one but a noteworthy amount of nasty flies killed.

    Carsten.