C# vNext feature request

At Ann Arbor Dot Net Developers meeting last night, Eric Maino was there. I don’t think he meant to open up the giant can of worms that is me when he asked “What kind of things would you like to see in the next version of C#?” Here is my list.

  • Static Imports

    yes like java!

    Sometimes extension methods aren’t as readable as just a method call. Ability to import static methods and call them without the class name would be super.

  • Drop var.

    Type inference rules. Can we drop the var? its noise.
    var x = 1;
    x = 1;
    which of these lines is more concise? At least make it optional. I don’t mind if you want to say var. Just don’t make me do it.

  • Better type inference

    Optional type parameters, since the compiler knows what I mean!
    peeps = List(new string[] {“Bob”,”Dorothy”,”Jane”});
    This is a List<T>, but I don’t need to say List<string> the type can be inferred via the List<T>(IEnumerable<T>) constructor.

  • Optional Whitespace Significance

    We all use whitespace formatted code anyway. Why not just drop the parenthesis and semicolons and make the whitespace actually mean something. Of course I say “optional” because not everyone will like it. It would be really cool to be able to toggle it throughout a file.
    #pragma whitespace significance enable
    public class Employee
      public Employee()
        name = string.Empty
        hireDate = DateTime.Now
      public string Name
        get
        set
      public DateTime HireDate
        get
        set
    #pragma whitespace significance disable
    public GiveRaise() {
    salary *=1.10;
    }
    #pragma whitespace significance enable
      public Promote()
        CLevel--

    The file would have to end in the same mode in which it were started, or the compiler can figure things out.

  • A hook into the compiler pipeline

    See boo.

  • A hybrid compiler

    At CodeMash, Joe O’Brien and Michael Letterle about how nice it would be to use the better suited language for any given task in .NET. We don’t want separate projects. We don’t want separate netmodules.

    I want it right down to partial classes. VB’s XML Literals and late binding are sweet. I want to use those if I need. C#’s everything else are what I prefer to work with.

    ReadYourFeed.cs:
    public partial class ReadYourFeed {
      Initialize(){
        rss.FirstChild.AppendChild(GetGenerator());
      }
    }

    ReedYourFeed.vb:
    Partial Public Class ReadYourFeed
      Public Function GetGenerator()
        Dim sig = <generator>SuperReadYourFeed 2000 1.2.3.4.5</generator>
        Return sig
      End Function
    End Class

    * I don’t know VB. Writing that VB took me much googling

  • A plugable compiler

    Similar to the above with boo, but almost the inverse. I want an open definition for the AST which the compiler uses to generate IL and I want a great API for building this AST myself.

    Next, I should be able to plug in my own parser/lexer which builds this AST. So the IL generation from the AST is entirely from the (now more than) C# compiler, but the parser is mine.

    This is really an abstraction and opening of the previous step. Instead of just C#/VB, I want it ALL!

  • Easier method currying.

    Dustin Campbell might like writing lots of code to do it in C#. I’m sure he does it all the time, but I’d like to be able to do it in FAR fewer lines of code.

  • F#’s pipeline operator.

    This is more readable
    {1..10} |> Seq.fold (+) 0;;
    than this
    Enumerable.Aggregate(Enumerable.Range(1, 10), (a, b) => a + b);
    or this
    (from i in Enumerable.Range(1, 10) select i).Sum();
    or even this
    Enumerable.Range(1, 10).Sum();
    Ok, well extension methods sure look a lot like the pipeline operator, so never mind on this request :)

It seems like I talked about other crazy stuff too, but I don’t recall what things they were.

5 thoughts on “C# vNext feature request”

  1. I must say, I disagree passionately about most of your suggestions/requests.

    Let me first preface the following comments with an important bit of information. I am in the consulting business and, as such, I often have to read code written by other developers and fix it or modify it. As I am sure you are aware, every developer has his/her own unique style. This is both a good and bad thing. The good should be pretty obvious. The bad, however, is that because everybody has their own style, it makes reading somebody else’s code difficult. Most of the suggestions you have proposed only make that job (deciphering someone else’s code) all the more difficult.

    Static Imports – Confusing. If I am reading code in ClassA and I see a method call DoSomething, I expect that DoSomething to be a method of ClassA. Static imports mean I can no longer make this assumption and, instead, have to remember more of the entire design of your code.

    Drop var – NO, just NO. This is just a terrible idea. C# is not a dynamic language. I do not want to have every typo I make end up being a new dynamic variable. I already struggle with this enough in JavaScript.

    Better type inference – Unless I misunderstand, I think I agree with this one (at least, based on the example you gave)

    Optional Whitespace Significance – OMG! No no no. Please no. If you don’t like C#’s syntax, use a different language. It’s bad enough that people can’t agree on whether to put braces on the same line as constructs, tabs vs spaces, commenting styles, etc. Bad programmers are far more common than good ones, and giving the bad programmers more options for creating write-only code only makes my life more miserable.

  2. Hello Anonymous,

    I usually wouldn’t reply to an Anonymous person, but your response is well written.

    I too have to often read the code of others. This is life. The complexity or verbosity of a language doesn’t make this more difficult or more easy. I’ve decyphered perl code that was more complex than 8086 assembly and I’ve read perl code that was easier to read than Java in articles on java world. The language and its features do not matter her.

    Static imports might be a little confusing, but Java has them and they don’t confuse the java folks. Your argument against would be the exact same argument against extension methods, but we have extension methods. Refactoring tools and good IDE tools make this a trivial no brainer. F12 go-to-definition will still work in Visual Stuido.

    Your argument here against var shows that you don’t understand what var in C# is. It is not dynamic. C# 3 has no dynamic variables or dynamic typing. it is not quasi-dynamic. it is absolutely no different than explicitly putting a type before the variable declaration except that the compiler fills in the type from the assignment portion of the statement.

    Type Inference we agree on. Good!

    Whitespace: you have obviously never read or written either Boo. Python or Yaml. These whitespace significant languages have never suffered from what you describe.

    Sorry, but on the three points you differ with me on, you arguments don’t hold up. I am open to changing my mind on these requests, but I would need to be swayed and these points aren’t swaying me.

  3. I pretty much agree on everything aside 2 things.

    The whitespace i hate in languages like VB, because when you have very long code, it’s just plain hard to see where something ends, with brackets it’s completely non-trivial, cause they sorta jump into your face to say: hey look, i start here & end here ..i love brackets :)

    And in the example where you say: {1..10} |> Seq.fold (+) 0;;
    is more readable, sorry, but i find: Enumerable.Range(1, 10).Sum();
    to be the most readable (and understandable) of what is going on. The F# example just looks like a bunch of mathematical gibberish to me.

    Dropping the var doesn’t shock me at all tho i can understand some ppl might wanna keep it as a visual queue (like me for brackets).

    Then for static imports ..i guess it won”t change much from extension methods, just do a (go to definition).


    Robert

Comments are closed.