C# 3.0? You haven’t even shipped 2.0 yet?

One of my readers commented (and I’m paraphrasing here):

Why are you asking me about features for the next version of C#, when the 2.0 version hasn’t even shipped yet?

A fair question.

One of the problems that we have in the tools division is the long lead time between the time when we’re done with a product and the time that it’s actually available to our customers. Delta a few small items and some bugfixes, the C# compiler is essentially done for Whidbey, so that’s why we’re thinking about the next version.

We’ve always had this offset, but because we’re attempting to expose our designs much earlier than we have in past, it may look strange from the outside. As involving customers early on in design becomes more common, this should be less weird.

Hope that explains things a little better.

Comments (21)

  1. S N says:

    Would you consider letting people write ILASM in a C# program within unsafe context similar to coiding ASM in C & C++?

  2. jaybaz [MS] says:

    The long lead time is almost exclusively in the compiler. The rest of the division is still working hard to ship Whidbey.

    The lead time on the C# Language is even longer than the C# compiler, which is longer than just about everything else.

  3. I notice that Anders was using the following construct extensively in a recent video:

    var x = new Dictionary<Foo,Bar>();

    which infers a Dictionary<Foo,Bar> type for x.

    Will we see this construct in Whidbey?

  4. Eric says:


  5. I hope so. There were a number of fantastic new ideas Anders mentioned in his talk.

    In particular mixins ard interface default methods are great!

  6. Eric: how can we make suggestion for C# 3.0 if you won’t tell us what’s in 2.0?

  7. Eric says:


    The spec for V2.0 is publicly available at http://msdn.microsoft.com/vcsharp/language

  8. Steve Jackson says:

    I’d be shocked if this wasn’t mentioned before, but why not include a little bit of regex syntax sugar in C#. With the string object on the left hand, the compiler could prebuild a regex object from string and perform a Regex.Match operation using the ~= operator, ala….

    if ( myString ~= "d" )


    Of course, if I had that, I’d want regex support in switch statements too, but…

  9. When you were asked if we’ll see the

    var x = new Dictionary<Foo,Bar>();

    in Whidbey, you said, "Perhaps." I took that to mean that you knew the answer and couldn’t reveal it. Did you instead mean that the spec isn’t final yet? In either case, it’s hard to comment on 3.0 before knowing what will be in 2.0. Not impossible, of course, and still useful, but still difficult.

  10. Eric Gunnerson says:


    Sorry for my short comment earlier.

    When you say that you don’t know what’s in V2.0, I don’t understand what you’re saying. Are you saying that without using it it’s hard to give an opinion, or something else.

    On the "perhaps" front, it’s hard to be more precise than that. We’re a *long* ways from having anything definite for V3.0, so at this point "perhaps" really means:

    "This is something we’re considering doing, but we haven’t completed detailed language design discussions about it, nor do we know enough about the other features to know where it falls in the priority list."

    Or something like that. Does that make more sense?

  11. Norlan Mumar says:

    could we have a delete operator in C#, that will be use for deterministic disposal of the object, instead of using the "using" construct. e.g.



    //assuming class x implements IDisposable

    X objX = new X();


    delete objX;


    instead of this:

    using( X objX = new X() ){




  12. Ken says:

    Norlan – your "delete" code is not exception safe, while your using code is.

    This is a big reason why I rarely use delete in C++ code – storing the pointers in deterministic lifetime wrappers takes the burden of exception handling out of my pointer management.

  13. Damien asked if we’d see the "var" construct in Whidbey. I took your perhaps to mean that the Whidbey specification wasn’t finished, and that "var" might still appear. Thus my comment. Reading your reply, however, it seems that you simply read Damien’s comment as referring to 3.0, not Whidbey. Is that true?

    If so, and such a major change will not make it into Whidbey, then please excuse my comment. The publicly available documentation and library is more than enough to explore the new features of C# 2.0 and begin to make suggestions for 3.0.

  14. Eric says:

    That’s much clearer.

    Yes, we are virtually locked down on 2.0 features, and there’s no chance that something like "var" will show up in that release.

    It may show up in future releases. Sorry for the confusion.

  15. It was just a question. Anders’ used of the "var" construct was probably impromptu (and likely casued by the laboriousness of handwriting type declaration and initialization statements), and based on his experiences with 3.0 planning.

    Im sure that in the time before Whidbey is released, there might be opportunities to make minor changes or improvements, but that it hasnt been decided which changes or features to throw resources at.

    My question wasnt so much a question as a request or vote. Probably not worth getting worked up over, though.

  16. Matthew W. Jackson says:

    Here’s the solution to the double-typing problem in C# that I’ve been using for a bit now. This is the third or so revision and I’m mostly happy with it.

    The $params$ part of the expansion may seem weird at first, but it’s a compromise that allows two things:

    1) The default constructor will be used if you don’t change it.

    2) Intellisense will pop up when you do change it.

    I would prefer for VisualStudio to ask for the variable name first, but I haven’t determined a way to do this yet. Maybe functions in the expansion instead of literals? Is there a good guide on writing these things?

    <?xml version="1.0" encoding="utf-8" ?>

    <CodeSnippet Format="1.0.0">


    <Title>Variable declaration/construction</Title>


    <Description>Expansion snippet for variable declaration and construction</Description>

    <Author>Matthew W. Jackson</Author>










    <ToolTip>Variable name</ToolTip>










    <ToolTip>Constructor parameters</ToolTip>




    <Code Language="csharp" Format="CData"><![CDATA[$type$ $name$ = new $type$$params$);]]></Code>



  17. Matthew W. Jackson says:


    I forgot to remove this line from my snippet expansion:


    When I wrote this snippet, I didn’t fully understand the meaning of SnippetType, but I’ve since learned its purpose.

  18. Can we have property scoped variables in C# 3.0?

    This would force all getting/setting of the value to go through the property.

    Syntax Suggestion:

    class MyClass


    public string MyProperty


    string _myVariable;

    get { return _myVariable; }

    set { _myVariable = value; }


    void MyMethod()


    _myVariable = "Hello"; //Compile Error

    MyProperty = "Hello"; //OK



    This would be particularly useful for when you want to always raise an event when the property value changes.

  19. Jeffrey Sax says:

    Another suggestion: clean up the floating-point math stuff. Some of this is BCL material, but I miss the following:

    + Implement the ‘checked’ keyword for FP math (optionally specifying which conditions to trap)

    + A ‘long double’ type would be really nice. Use 16 bytes instead of 10 if you like. They will likely only be used for intermediate results, anyway. (Not even VC++ has it, even though it comes ‘out of the box’ with 99.99% of the hardware as the native FP type.)

    + Use the longest FP type for intermediate results. I see absolutely no reason why less accuracy would be an advantage.

    + Make c# fully compliant with the IEEE-754 standard.

  20. Jason Brown says:

    How about pure function support? I’ve never been able to successfully implement something close to lambda-binding that you get in say SML (Standard Meta Language). I know that there is an SML .Net from your lab in Cambridge UK, but I think having a lamba binding equivalent in C# would be a leap in language design. This way we can pass functions that have bindable scop, oh the thought…..

  21. MBA says:

    Helpful For MBA Fans.

Skip to main content