CSharp Language Specification, Version 3.0 Available for Review

The CSharp Unified Language Specification is now available for review. This specification pulls together information from the CSharp 1.1, 2.0 and 3.0 specifications into a single unified document.

The CSharp community will have approximately one week, until about August 5th 8th, to review this specification. Please submit your review of the specification as a comment to this blog.

Note: We had to move this forward due to some internal schedule changes that we could not control. Please get your comments to us by the 5th.

kick it on DotNetKicks.com

Comments (26)

  1. Visual Studio 2008 Beta 2 was released to the web for download today. The releases are available both

  2. Visual Studio 2008 Beta 2 was released to the web for download today. The releases are available both

  3. You’ve been kicked (a good thing) – Trackback from DotNetKicks.com

  4. Download Visual Studio 2008 Beta 2. All the required links are here…

  5. You guys rock! This needed to be done for a long time (and I’d put in requests on Connect a long time ago, accordingly).

    A week to review a spec this big isn’t very long though for people who are most likely to be doing it in their spare time. I appreciate the existence of the spec, but the "public review" period seems like a fairly useless token gesture. A few months of regularly updated public drafts would have made more sense. This is better than nothing, but – as far as public review goes – not nearly enough.

    Still, very pleased you finally combined the specs 🙂

  6. Peter Ritchie says:

    One week to review 500 pages, I’ll try my best…

    Section 10.5.3. isn’t very clear.  It mentions "acquire semantics" and "release semantics for volatile fields; but acquire/release semantics are not sufficient to avoid instruction re-ordering by a processor (e.g. IA-64).  10.5.3 starts by describing the reordering of instructions by the compiler, runtime, or hardware (processor) and then goes on to describe acquire/release semantics.  This suggests that declaring volatile field is sufficient to suppress all reordering and make access of an atomic field thread-safe.  A memory barrier of some sort would be required to suppress processor instruction reordering.  I’d have to research more closely, but I suspect the example code is not thread-safe on IA-64.

  7. Peter Ritchie says:

    Section 8.12 has the following detail:

    where x is an expression of a reference-type, is precisely equivalent to


    try {


    finally {



    I don’t think it’s accurate to say it’s "precisely equivalent".  I think it’s more equivalent to:

    Object temp = x;


    try {


    finally {



    lock(x) {…} has a distinct advantage over


    try {


    finally {



    … in that the following:



    x = new Object();


    ….will not generate a SynchronizationLockException.

  8. Peter Ritchie says:

    The following sections have reference source not found errors in the Word document (where the # of errors is in parentheses):

    3.8 (2)

    4.4.1 (1)

    4.5 (1)

    7.2.1 (1)

    7.2.7 (1) (2)

    7.5.4 (1)

    7.5.7 (5) (1)

    7.5.11 (2)

    7.5.13 (1)

    7.9.9 (1)

    7.9.11 (2)

    7.14 (1)

    7.14.1 (2)

    7.14.2 (2) (1)

    8.2 (2)

    8.14 (4) (1)

    10.1.2 (1)

    10.1.3 (1)

    10.1.6 (3)

    10.3.1 (1)

    10.3.2 (2)

    10.12 (1)

    10.14 (3) (2) (1)

    11.1.2 (1)

    13.1.2 (1)

    17.2 (1)

  9. A última versão da especificação do C# que inclui a versão 3.0 foi liberada para download e revisão pela…

  10. NyaRuRu says:

    The runtime compilation of Expression Tree is implementation-dependent?

    There seems to be no explanation of ExecutionScope class in this spec.


    I don’t know whether above case is "correct behavior" for any C# compiler or Microsoft specific.

  11. NyaRuRu says:

    I complement the last my comment.

    In the case of delegate, there is no problem.

    Func<bool, Func<bool>> identity = cond => () => cond;

    var _true = identity(true);


    var _false = identity(false);



    // True False True … OK

    This result is guaranteed by this spec, I think.

    But in the case of expression tree, the result is different from the delegate case (in Orcas beta 2).

    Expression<Func<bool, Func<bool>>> expr = cond => () => cond;

    var identity = expr.Compile();

    var _true = identity(true);


    var _false = identity(false);



    // True False False !!!!!!

    I have not found any definition or statement that guarantees the semantics of "compile-time generation of Expression Trees" and "runtime compilation of Expression Trees".

    I think this spec is where the semantics should be declared.

  12. ccalvert says:

    I wanted to thank everyone for the comments you have sent in so far. The folks on the team who are creating this document have found them very useful. Please keep them coming.

    I also want to apologize that we had to pull the date for the end of the review in by a few days to the 5th. There are some things we can’t control, and this was one of them.

    – Charlie

  13. Marek says:

    The following bits should be better specified.

    if ei is an anonymous function or a method group, an explicit parameter type inference (§ is made from ei with type Ti

    otherwise an output type inference (§ is made from ei with type Ti

    It’s unclear what happens when there is no explicit parameter or an anonymous method or lambda expression are parameterless.

    All unfixed type variables Xi which do not depend on (§ any Xj are fixed (§

    I think "do not depend on" should be "do not depend directly on" in this particular case.

  14. Marek says:

    I wanted to review "A.6 Syntactic grammar" but it seems to me the section is completely out of date. It looks like it was copied from C# Standard Version 1 because previous version (v2) of C# standard contains more information .

  15. Marek says: Anonymous types

    The section should list all expressions which are non-assignable to anonymous type properties and not just null and unsafe types.

  16. Marek says:

    I am wondering why a type used in a collection initializer must implement IEnumerable. It makes things just more complicated.

  17. Eric Newton says:

    Ok, so after being published on the VS Start Page on Aug-9th, how can we submit feedback?!

  18. John says:

    Please please please add to C# a way to do C++/CLI’s "protected private", aka "protected AND internal" This would be a HUGE help.

  19. Peter Wone says:

    To gild refined gold, to paint the lily,

    To throw a perfume on the violet,

    To smooth the ice, or add another hue

    Unto the rainbow, or with taper-light

    To seek the beauteous eye of heaven to garnish,

    Is wasteful and ridiculous excess

    King John. Act iv. Sc. 2.

    To put it more directly if less elegantly, how about fixing the bugs instead of mucking about with syntactic sugar for things we can already do with design patterns and some common sense?

    I could, for example, send you some code that works perfectly on a single CPU system but intermittently hangs on a multi-CPU system when it hits Control.Invoke() – the clue here is that this problem only occurs when the invoked method is on another object (visitor pattern). When you merge the method into the class of the object on which it operates the problem goes away.

    Perhaps it might be wise to solve the problems we have before creating new ones?

    For example, how about a straightforward way to install a global exception handler on a windows service? As things stand, when the network glitches and a socket closes unexpectedly you get an InvalidOperationException in mscorlib and remoting dies taking out the whole service.

    (If there is already a way in 2.0 to handle this scenario please tell me and I will sing your praises from the hilltops.)

  20. Eddy Luten says:

    Little late, but: I’d like to see some form of #include in C# in which we can include C# files. In many of my projects I had to do cut-n pasting namespace usage for each file. I’d like to put all my "using" declarations in a single file and include that across the project.

    If there’s a hack to work around this. Please let me know at eddyluten AT gmail DOT com

  21. Jon Skeet says:

    I’ve been writing about type inference *very* recently, based on the previous C# 3 spec (the "add-on" version). In other words, I think I know reasonably well how it works in any particular situation.

    This morning I looked at the spec to see how well my understanding matched up to the current spec… and I couldn’t understand a word of it! Okay, that’s going a bit far, but the type inference section is really, really dense. That’s not completely inappropriate for a spec, but I don’t think it would be reasonable to expect anyone to read that section and learn about type inference from it, without a significant starting point.

    Of course, it’s easy to criticise – I fully appreciate that actually *fixing* the readability issue is insanely difficult.

    (And to echo some other comments – thanks for putting this out!)


  22. ad &7.2.3

    After August 5, but this is just a question anyway. since this is of interest for me I merely checked this section on "Unary Operator overload".

    Some time back I overloaded unary increment / decrement on my numeric type however I saw no difference between post and pre increment ie

    NUM res1,res2,org = new NUM(5);

    res1 = ++org;

    res2 = org++;

    res1 and res2 result exactly the same (6 I reckon) however res2 should be 5 and org increment to 6 after this assignment.

    In C++ one could implement this due to different operator syntax, in C# this can’t be done, which is understandable. However the semantics between pre and post operators should be different (as above expected).

    Just wondering whether or not thus is fixed.

  23. Oops, I might a slight mishap in previous note, both 6 is logical, res2 probably results in 7 in given sample. Experience told me at least the userimplemented postincrement is treated the same as preincrement.

  24. James Swaine says:

    The new language extensions don’t appear to have made it into the grammar in the appendices.

  25. Usman Ahmad says:

    After reading this i am very thankful to Microsoft team to provide us such a best collection.

  26. Shehzad says:

    There is no clear difference between Moudle of Visual basic and that is corresponding to C#. Please let me know that what is the Clear difference between them… pankhawala1234 AT yahoo DOT com