My Wishlist for C# 4

[Edit: fixed the not-ready-for-publication problems] 

There seems to be more than few people blogging about what they hope C# 4 will do for them.  I haven’t seen one that really synchronizes with my thoughts, so I’d thought I’d post my own list.

Variance

A good story with regard to variance with generics is vital for upcoming versions of C# 4.  You could argue that this should have been done in 3, but, unfortunately, that wasn’t the focus.  I think this really needs to be done for 4; and if Eric Lippert’s blog is any indication, that may come true.

Design By Contract 

Design by Contract (DbC) means programmers can define verifiable interfaces.  This explicit intention information is then used by the compiler to greatly increase the compile-time checking it can do.  In most cases this means no checking need be done at run-time because the compiler has verified the that condition cannot occur at run-time, increasing reliability and improving performance.  There’s hint of this in the framework already with the internal classes ImmutableAttribute and InvariantMethodAttribute.  First-class language support for DbC would go a long way to being able to write more reliable software.

Concurrency

Various leaders in the industry (Microsoft included) are recognizing the processor speed improvements will essentially stop being vertical and continue to be horizontal (i.e. instead of increases in processor speed, increases in processors or cores will be the norm).  This means that in order for applications to utilize that type of system processing throughput concurrency will become more mainstream.  Microsoft has various concurrency initiatives going on (like the Parallel Framework Extensions).  It’s only logical that lessons learned from this project not long will make their way into the BCL and the .NET Framework but also into the respective languages (C# included, I hope).  In this respect I hope that concurrency issues become first-class citizens in the library.  This would include things like immutability.  In the spirit of Agile development, the sooner this gets into the language the sooner it can be embraced and evolve.

Object-Oriented Programming

Much like Jon Skeet, I believe the language designers should recognize that C# is an object-oriented language first and foremost.  This fact should continue to focus what, if any, aspects of other programming paradigms are added to the language. Paradigms like Aspect-Oriented Programming, Functional Programming, etc.

infoof, memberof, propertyof, eventof, methodof Operators

The information these operators require is so easy for the compiler to simply dump in the IL stream.  For users to do the same thing requires that they have a string containing the name of the member in question–which can’t be checked at compile time and leads to maintenance nightmares.  Imagine what life would be like without the typeof operator forcing use to use code like this:

    Type type = Type.GetType(“MyNamespace.MyClass”);

Instead of:

    Type type = typeof(MyNamespace.MyClass);


…if I rename MyClass to UsefulClass no refactorying tool I’ve see will modify the “MyNamespace.MyClass” string and compilation will succeed and lead to a runtime-error.


Cleanup Some Long-standing Issues.


The above and variance could be viewed as a long-standing issues; but, I think they deserves to be called-out on they’re own, they would be huge improvements.  Detection of recursive properties, for example.  The C# team have a backlog of a few things like this; now’s the time.


Extensible Compiler


Years back my original idea for this was to have an IDE that automatically corrects mistakes.  e.g. if an “; expected” error was spit out, the IDE could intercept it, correct the code, and recompile.  But, this extensibility idea can be so much more than that.  This sort of extensibility could introduce Aspect-Oriented Programming fundamentals or Domain-Specific Language abilities without the language really understanding the concepts at all.  This extensibility would be very powerful for programmers and would give them the ability to evolve their language without being tied to the release schedule of the C# team.


Thinking Out Loud


Class-scoped aliases: Aliases in C# are a bit of a pariah, they’re at global, file scope; making them not all that useful.  In C++, for example, it’s quite common to declare type aliases within a class declaration (usually based on a templated type).  It would be nice to be able to create an instance of a type based on an alias within a class.  E.g. MyType.MyAlias o = new MyType.MyAlias;


 

kick it on DotNetKicks.com

9 thoughts on “My Wishlist for C# 4”

  1. A couple more features I’d like to see:

    “static using” (introduce all non-instance members, including nested types, into the name search space)

    I know a lot of people have said that this just makes it more difficult to see what function is being called, but it’s no worse than extension methods, and it enables other cool things like:

    assembly-wide generic parameters (like a C++ incomplete type) can be emulated by changing a namespace into a generic partial class, but you lose the ability to import members with using — unless there is “static using” support. Lack of support for incomplete types means a lot of unnecessary coupling.

  2. @Ben: I’m not sure I see the value in essentially being able to import static methods from other classes into the current class. I don’t see, for example, the benefit of typing Max(x,y) instead of Math.Max(x,y) outweighing the drawbacks (name collisions, brittle code, increased compile-time dependencies, etc.)

  3. As annoying as the familiar “; expected” is, I am not yet confident enough in compiler technology to have the compiler start modifying my code for me. I want to be in control of how errors are corrected, especially when the fix is that trivial; that cost of getting the fix wrong is potentially far greater than the cost of fixing it manually.

    I completely agree that the C# team needs to jump off the functional bandwagon and remember that C# is an object-oriented language first and foremost. However, I am curious as to how you reconcile this with your MSDN article entitled “Inferred Typing with Factory Methods as Extension Methods” (http://msdn2.microsoft.com/en-us/vcsharp/bb978522.aspx#). In that article, you advocate using extension methods to gain type inference, while not actually referencing the object on which the extension method was invoked. Now, depending on which side of the fence you are on, extension methods either make C# more object-oriented, by making methods which operate on an instance of a particular type appear as members of that type, or less object-oriented, by blurring the lines between static and instance methods. But I don’t see how you could argue, from either side of the fence, that the technique that you present in that article adheres to object-oriented principles.

    Oh, and your link to Jon Skeet’s blog includes the “CommentPosted” argument in the query string.

  4. Regarding DbC meaning less checks at runtime: As long as we live on CLR 2.0, we need the runtime checks – otherwise the IL code cannot be verified by the CLR.

    Regarding class-scoped aliases:
    These will never be anywhere similar to what can be done in C++ (template metaprogramming abuse ;).
    I hope C# will never get these “typedefs”, since people will just go crazy with
    static class Foo { using Bar = List> }
    just to be able to write Foo.Bar.

  5. yeah, I agree with the DdC. Hopefully, they’ll get Spec# integrated into the core. It’s looking pretty promising.
    http://research.microsoft.com/en-us/projects/specsharp/

    –Another thing I’d like to see would be a built-in exception type when throwing an exception inside a property setter, such as PropertyValueException. Even though properties are methods under the hood, it doesn’t make sense to throw an ArgumentException when a property value is being set.

  6. @Jeff +1 on Spec#; but, it’s not going to happen before 2012.

    The value assigned to a property might not logically be an “argument”; but I don’t think a BCL Exception to do this may ever happen. 1) Existing framework property setters that are currently throwing ArgumentException (and derivatives) can’t change–that’s an existing contract. 2) adding another exception used by new BCL property setters that get thrown in the same circumstances as ArgumentException is thrown with other propery setters would be confusing.

    You could always just create your own OperandException exception; which would be more logical to assignments (including properties) and other operations (like addition, subtraction, multiplication, etc.). but, I don’t think it’s too much of a stretch to think of an operand as an argument.

  7. I’d love to see support for generic pointers too. I’ve been pestering MS for years about this not only because it can simplify certain kinds of code but because I really don’t think it is a major issue.

    I think a new constraint type (ensuring the type is always a value type whose address can be taken) would make thus easy-ish to do.

    One day perhaps, one day…

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>