What do you want in C# vNext?

Posted by Jeremy Miller on November 26, 2007

I’m somewhat of the opinion that static typed languages are closing in on being an evolutionary dead end, but let’s just say that C# is still important for the foreseeable future.  That being said, what do you want for C# vNext?  If we have to be constrained by static typing, I vote for making C# more like Objective C (not that I’ve ever coded in Obj C, just that it seems to have the things I want.).  My little list in order (not that I expect much of it to happen) is this:

  1. Mixin’s. I found myself really wanting this for a framework I have in my current project.  Extension methods are okay, but I’d rather make it all the way to Mixin’s.  Obj C can do it as a static typed language so it’s definitely possible.  Heck, you can kind of do it in JavaScript.
  2. Symbols.  Reflection based solutions could be so much easier with Symbols.  I’d love to have compiler safe equivalents to Ruby Symbols.
  3. Make hashes a language feature.  I keep bumping into frameworks that really want to pass around hashtables.  If you absolutely have to do that, I wanna do var hash = :key => “red”, :key2 => “green” in one line of code.  Somebody recently commented that object initializers might be a decent compromise.
  4. Automatic delegation ala Ruby or Objective C.
  5. Metaprogramming!  Method Missing magic!  I’m not holding my breathe on this one because it sounds like a bridge too far for me.  Give me metaprogramming and mixins and I think we can do AOP like things with less effort.
  6. Everything is virtual by default to make mocking easier

Anyway, what’s your wish list?

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.eschertech.com David Crocker

    Non-nullable reference types

    Contracts (pre- and postconditions) that are turned into quotation metadata (a bit like ReflectedDefinition in F#) so that we can do model-based testing

  • http://www.CodeWise.nl Jelle Hissink

    non-nullable reference types
    spec# integration
    for the rest focus on libraries and frameworks like ASP.MVC

  • titrat

    Im keen on supersized Enums – which could be stacked like structs, for example. java is a step ahead in this area.

  • http://dotnet.agilekiwi.com/blog/2008/02/enhanced-automatic-properties.html John Rusk

    Personally, I’d like to see automatic properties enhanced so that, while they would still generate the backing store, they would access it via programmer-defined methods. Keeps the conciseness of the currrent automatic properties, but adds a lot more power: http://dotnet.agilekiwi.com/blog/2008/02/enhanced-automatic-properties.html

  • Kaveh Shahbazian

    Microsoft must stop changing C# so much, so fast. Instead they should make a 3rd language mainstream, Something between F# and Scala. Sure I will use it. Because for me, I must hack the shortages in C# and some bad designed aspects of it. For example generics are so limited in C# that it is in many scenarios useless. I want higher order data types and higher order structure of data (like lisp) and higher order data structures.
    It seems Scala is a good choice. But it is on JVM. And F# with a more polished syntax and a good support can be it for sure!

  • Mike

    “Nothing, absolutely nothing. The C# syntax is being more complicated and complex. I would focus on extending .NET library instead of useless features in the language.”

    It’s inevitable to get replies like this it seems. If a feature is useless to you, don’t use it. But why should we suffer under your incompetence by not having these features at all?
    Also, since do we have to choose between language features and library development? Did not .NET 3.5 introduce both (new C#/VB compilers AND new namespaces such as System.Linq).

    Please use brain before posting, kthx!

  • http://msmvps.com/jon.skeet Jon Skeet

    @SirMike: Don’t make the mistake of thinking that LINQ=LINQ to SQL, or that LINQ to SQL is the only LINQ to databases provider.

    For in-process stuff, a lot of what you can do in LINQ can certainly be done without LINQ – but LINQ makes it cleaner, more readable, and generally nicer.

    Jon

  • http://www.sirmike.org SirMike

    Nothing, absolutely nothing. The C# syntax is being more complicated and complex. I would focus on extending .NET library instead of useless features in the language.
    All the Linq stuff is very interesting at first glance but when one starts working with that, he realizes that it does only very simple things. Linq to SQL is just veeeery simple mechanism good for fetching data from Notrhwind database. When you want to use it with advanced logic (with stored procedures in DB) it becomes useless. Even Scott Guthrie wasn’t able to help me and said something like “Sorry, it’s impossible”. ;) MS should work on that harder because it’s a veeery long way in front of them to create a good ORM.

  • http://msmvps.com/jon.skeet Jon Skeet

    @Sergio: There’s no need for anything beyond C# 3 to make line handling easy.

    I’ve already written a LineReader : IEnumerable class (very simply – it’s not like it took a brainwave to come up with it) where you pass in enough information to make a TextReader *at the right time*. That “right time” is when GetEnumerator() is called. You can then do:

    (Apologies for spacing issues – nasty proportional font…)

    foreach (string line in new LineReader(…))
    {
    }

    The file will be closed at the end of the foreach.

    *And* you can use it very nicely in LINQ:

    var query = from log in Directory.GetFiles(logDirectory, “*.log”)
    from line in new LineReader(log)
    let entry = new LogEntry(line)
    where entry.Type = EntryType.Error
    select entry.SourceIPAddress;

    Bingo, you now know all the source IP addresses which encountered errors, across many log files, only ever loading a line at a time, with pretty much no fluff in the code to get there.

    LINQ to Objects rocks, and people aren’t making *nearly* enough fuss about it…

    Jon

  • http://judahgabriel.blogspot.com Judah

    I’d like to see design-by-contract concepts into C#.

    This would clean up code significantly — imagine something like a [NotNull] attribute on your params instead of writing a million different null arg checks.

    It would result in a codebase with fewer bugs.

    I’d also like to see more functional concepts in C#: Spec#’s research is promising and also could result in code with fewer bugs.

    That’s what I ultimately want. Metaprogramming and AOP is nice, but really what I want is fewer bugs in my code. I want language and runtime help with this. Design by contract is one such way to accomplish this.

  • http://www.camocarzi.com Cameron Singe

    I reckon more ruby like features as mention in the article, what I would really love is being able to pass a block into a conditional statements

    for example

    return error_msg if !person.isValid()

    I would also love to see the allowed use ? for boolean statements and the unless keyword, although not the most critical features ever, they do make for more elegent code

  • http://grabbagoft.blogspot.com/ Jimmy Bogard

    Generic covariance and contravariance. When you need it, you really really need it.

    And doesn’t virtual by default make it more difficult to abide by LSP? Seems like that can be solved with products like TypeMock and techniques like “subclass and override”.

  • John Jeffery

    One feature I admire in Groovy is the “?.” operator. As I understand it, it allows you to traverse objects but stop if one of the objects turns out to be null. For example the expression “foo.Bar.Baz” will throw a NullReferenceException if the “Bar” property happens to return null, but “foo.?Bar.?Baz” will return null when the first null is encountered.

  • Stuart Gtreen

    Everytime I read your blog you come over as a complete moron…

  • Chyld Medford

    Mixin’s rock!

  • http://dejan.lekic.org Dejan Lekic

    BCS, not just mixins, D actually has more/less everything mentioned in the article – some of those for years (already years passed, phewww).
    Mr. Miller, so much for “static typed languages are closing in on being an evolutionary dead end” talk…

    Kind regards

  • BCS

    a clarification: D has a type of mixins, if it’s the type you are looking for is another matter.

  • BCS

    there is a language that is much like what you seem to be asking for: The D Programming Language. Even If you don’t want to use it, it would let you get your hands dirty with a language that has most of what you are asking for. 1, 3, 5 and 6 for sure, maybe 4 and I don’t know what 2 is but it might have it.

    http://www.digitalmars.com/D

  • http://luke.breuer.com/ Luke Breuer

    I agree with the above and add:

    A) I’d like a way to specify that variables should be disposed of, within the current method, after they are last referenced (and in the relevant finally statements). This should not be too hard, since the compiler knows the last time they were referenced (this is required for .NET garbage collection). Unfortunately, this feature might break the “pit of success” goal for .NET.

    B) Ability to refactor an anonymous type into a declared type. This is not currently possible if one wishes to retain the named parameter approach over the constructor approach (new Foo() { Bar = 2 } vs. new Foo(2)) and get immutability. There is no way to allow the former kind of assignment with readonly fields/properties (only the constructor has permission to write to them).

    C) A possible alternative to B, and very useful in its own right: named parameters. Calling a method and passing (true, true, false, true) is not readable at all, or as Scott Bellware would say, _soluble_.

    D) Better type inference. This is a hairy issue, to which anyone who has debugged Haskell type errors can attest. However, I think excellent IDE support would mitigate this issue. Being able to access anonymous types, strongly typed, outside of the method in which they were declared, would be quite helpful, especially for rapid, prototype work. It should be possible to use refactoring tools to make types explicit if necessary.

    @Jeremy Miller: your justification for making everything virtual by default is really a hack, IMHO. Eric Lippert has an excellent blog post on why most of the .NET framework classes are sealed [1] that addresses this issue. In short, unless your methods are designed to be overridden, you are making them virtual only for testing purposes and in doing so, someone can override them in a way for which you did not plan. Eric Gunnerson also discusses this [2] and there is a decent amount of discussion in the comments. Virtual by default is also a performance issue, which is one thing I think the Java HotSpot optimizer was built to overcome: figuring out which virtual methods are never overridden so that the vtable call can be elided.

    [1] http://blogs.msdn.com/ericlippert/archive/2004/01/22/61803.aspx
    [2] http://blogs.msdn.com/ericgu/archive/2004/05/17/133570.aspx

    @Chuggle: ListobjectListHoldingStrings = new List(); is tricky business. C# allows you to do this with arrays in a very hacky, non C#-ish manner because Java allows it:
    object[] objs = new string[1];
    objs[0] = 2; // ArrayTypeMismatchException

    There are a few options:
    1) make the lvalue immutable: acceptable (Listbecomes ReadOnlyCollection)
    2) copy the list: undesirable because, IMHO, it violates the principle of least surprise
    3) allow contravariance with IEnumerable, as it is immutable

  • http://noveltheory.com James Curran

    One thing I’d like to see, which I’d consider more of a bug-fix to v2 than a new feature for v3, is something which I’ve been calling a “contract”. It would essestially be an interface on steroids, and only used in generic contraints. I would be like in interface, but could also specify other things that the class must implement/have available, such as static members, operators, and ctor parameters,

  • http://www.NDepend.com Patrick Smacchia
  • http://www.mendelt.nl Mendelt Siebenga

    Mixins could be implemented by extending generics so you could do generic inheritance like this:

    class Mixin : T {
    …
    }

    Then you can use the mixin to extend a string like this:

    Mixin mixinString;

  • http://dotnet.agilekiwi.com/blog/2006/06/direct-support-for-symbol-names.html John Rusk

    Opps. Those links didn’t come through properly.

    The one about mixins is: http://kirillosenkov.blogspot.com/2007/11/john-rusk-on-extension-interfaces.html
    The one about symbols is: http://dotnet.agilekiwi.com/blog/2007/04/symbols-part-3.html
    and also this discussion on MS’s site covers symbols too: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=466000&SiteID=1&mode=1

  • http://weblogs.asp.net/fredriknormen/ Fredrik Normén

    I want multiple return values like:

    return 0, 1, 3;

    var x,y,z = myFunction();

    Ignore the second return value:

    var x,,z = myFunction();

  • john

    Jeremy, get a chance and look at the Nemerle (nemerle.org). It is already has a great metaprogramming subsystem. It is amazing!

  • http://aussiebloke.blogspot.com/ Stuart Carnie

    Extensible compiler pipeline…

    I want the ability to use (and build) custom attributes that will be executed during compilation. An example today is the [Obsolete] attribute, which shows a compiler warning..

    These custom attributes would derive from specific base classes to determine functionality. A good example is to look at the functionality exposed by PostSharp. Some features:
    * IL rewriting
    * Validation
    * AOP

    Extensible compiler pipeline – a-la Boo

  • Chuggle

    Everything virtual by default….oh yes please (crazy that it isnt like that already)

    I’d like to be able to do something like

    ListobjectListHoldingStrings = new List();

  • Sergio Pereira

    @CV
    C’mon. Are you’re seriously complaining about evolution? The C# language team has been pretty good at not introducing breaking syntax changes. You can elect not to learn the new stuff and continue writing using the 1.0 syntax if that makes you happy.
    Or are you complaining about software development in general?

  • Shadi Mari

    built-in design-by-contract support.

  • Carlton

    Agreed; stop changing things so much.

    Curious why people think static languages are going the way of the dinosaur?

  • CV

    C# yNext? Microsoft quit changing things on us. Give us a break so we can get some work done without learning all the new crap all the time. It makes me cringe every time I hear about some new cool feature I will never use. Please MS, stop the friendly fire!

  • Sergio Pereira

    @cmyers
    Oh, I knew that. But it’s not the same thing as having syntax to support it. Furthermore, that would enable the disposable object to more easily enforce the disposal of any required resource, commit what needs to be committed, destroy scopes, etc. Think about the File.Create example above, the logic to properly dispose the file handle could be baked inside that File class for everyone to reuse if desired.
    //File class
    public static void Create(string path, FileBuilder theDelegate)
    {
    using(StreamWriter file = new StreamWriter(path, false))
    {
    theDelegate( file );
    }
    }

    Another example, how many times we have written code to process a file line by line…

    public static void EachLine(string path, FileLineProcessor theDelegate)
    {
    using(StreamReader reader = new StreamReader(path))
    {
    string line = reader.ReadLine();
    while(line != null)
    {
    theDelegate( line );
    line = reader.ReadLine();
    }
    }
    }
    // usage:
    List commentBlocks = new List();
    File.EachLine(“myclass.cs”) : with (line)
    {
    if(line.Contains(“///”)
    commentBlocks.Add( line );
    }

    I don’t know … To me it just seems like something that could add value to the language.

  • nick

    Proper support for design by contract. You can only do this properly with support from the compiler, and it has to be a language issue.

    That removes the need for a lot of unit testing.

    The unit testing is better replaced with code analysis and automated unit testing.

  • http://dotnet.agilekiwi.com John Rusk

    What if symbols really were compiler-checked? No illusion then :-) This page links to several ideas that I’ve either linked to or posted myself.

    As for mixins, here’s one suggested way to do them, extension interfaces.

  • http://blog.ashmind.com Andrey Shchekin

    AOP is important, other things (like everything virtual or hashes) are out of place. Symbols seem dangerous, since they create an illusion of being compiler-checked.

  • http://keithhill.spaces.live.com Keith Hill

    Compile-time metaprogramming ala languages like Converge (http://digg.com/podcasts/Software_Engineering_Radio/446482). Having the ability to define new syntactical constructs like you can with Lisp’s defmacro could be very powerful and eliminate a lot of boilerplate code.

  • http://huntjason.spaces.live.com JH
  • http://www.evanhoff.com/ Evan

    Your list doesn’t really sound like c# vnext. It sounds more like Ruby.

    And that’s “on the way”.. :-)

    Evan

  • http://datamapper.org Sam Smoot

    @Bob:

    Ruby’s Symbols are interned Strings as well. The C method to get a Symbol is actually rb_intern() IIRC. They also suffer from the same drawbacks (they can’t be removed once added to a process). Which is why you should use them with care.

    A Symbol to represent a column or action name: Sure thing. A small finite set and nice performance gains.

    A Symbol to represent a user-name: Bad idea. Basically an infinite set that will crowd the symbol table and drag down performance across the board as a result.

    @Jeremy:

    Heh… default-virtual. I’ve been saying that for years. :-)

  • http://www.chadmyers.com/Blog cmyers

    @Sergio: Most of the things you describe are already available in C# with similar (and not much more) syntax. The using(){} block would handle everything you show there except the automatic commit of the Transaction Scope. But you could easily make an IDisposable wrapper class for that (a la MockRepository.Record() in Rhino.Mocks).

  • Sergio Pereira

    #6 looks improbable.
    One nice feature that came across my mind the other day would be a even better syntax for passing an anonymous delegate to a method. I’m specifically trying to get a similar syntax as in Ruby, where a block can be passed as the last argument to a method and the syntax looks oh so natural:

    //C# 4 from a dream
    Transaction.Scope() : with (trx)
    {
    obj1.DoSomething();
    obj2.DoStuff();
    if(obj2.Failed) trx.RollBack();
    } //commits by default.

    File.Create(“error.log”) : with (f)
    {
    f.WriteLine(someException.ToString());
    f.WriteLine(“Error at {0:d}”, DateTime.Now);
    } //file will be released here

    pdfDoc.CreatePage() : with (page1)
    {
    page1.MarginSize = 2;
    //..more stuff…
    page1.CreateParagraph() : with (par)
    {
    par.Align = Align.Center;
    par.AppendText(” blah blah blah…”);
    }
    }

    I got carried away, but I hope the idea makes sense.

  • http://bobondevelopment.com Bob Grommes

    The framework already has symbols. It’s called string interning. The only fly in the ointment is that you can add to the interned strings list, but you can’t delete from it. However, for many purposes it’s perfectly usable just the same.

    http://bobondevelopment.com/2007/05/19/optimize-memory-consumption-using-string-interning/

    I do agree that some syntax sugar would make string interning easier to use, though.

    I don’t think they’re going to want break people’s existing code by changing the default to virtual on methods. But, I could see it being a compiler option that’s off by default.

    I’m with you 100% on mixins. It’s by far the most useful thing that multiple inheritance has to offer. Presumably mixins could be implemented for significantly less effort than a full MI implementation.