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.
Comments
Anonymous
July 26, 2007
Visual Studio 2008 Beta 2 was released to the web for download today. The releases are available bothAnonymous
July 26, 2007
Visual Studio 2008 Beta 2 was released to the web for download today. The releases are available bothAnonymous
July 26, 2007
You've been kicked (a good thing) - Trackback from DotNetKicks.comAnonymous
July 26, 2007
Download Visual Studio 2008 Beta 2. All the required links are here...Anonymous
July 27, 2007
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 :)Anonymous
July 27, 2007
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.Anonymous
July 27, 2007
Section 8.12 has the following detail: where x is an expression of a reference-type, is precisely equivalent to System.Threading.Monitor.Enter(x); try { ... } finally { System.Threading.Monitor.Exit(x); } I don't think it's accurate to say it's "precisely equivalent". I think it's more equivalent to: Object temp = x; System.Threading.Monitor.Enter(temp); try { ... } finally { System.Threading.Monitor.Exit(temp); } lock(x) {...} has a distinct advantage over System.Threading.Monitor.Enter(x); try { ... } finally { System.Threading.Monitor.Exit(x); } ... in that the following: lock(x) { x = new Object(); } ....will not generate a SynchronizationLockException.Anonymous
July 27, 2007
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) 7.4.2.11 (2) 7.5.4 (1) 7.5.7 (5) 7.5.10.1.2 (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) 7.14.4.2 (1) 8.2 (2) 8.14 (4) 10.1.1.3.1 (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) 10.14.4.1 (2) 14.14.5.1 (1) 11.1.2 (1) 13.1.2 (1) 17.2 (1)Anonymous
July 27, 2007
A última versão da especificação do C# que inclui a versão 3.0 foi liberada para download e revisão pela...Anonymous
July 28, 2007
The runtime compilation of Expression Tree is implementation-dependent? There seems to be no explanation of ExecutionScope class in this spec. http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1861599&SiteID=1 I don't know whether above case is "correct behavior" for any C# compiler or Microsoft specific.Anonymous
July 28, 2007
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); Console.WriteLine(_true()); var _false = identity(false); Console.WriteLine(_false()); Console.WriteLine(_true()); // 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); Console.WriteLine(_true()); var _false = identity(false); Console.WriteLine(_false()); Console.WriteLine(_true()); // 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.Anonymous
July 30, 2007
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
Anonymous
July 31, 2007
The comment has been removedAnonymous
August 01, 2007
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 .Anonymous
August 05, 2007
7.5.10.4 Anonymous types The section should list all expressions which are non-assignable to anonymous type properties and not just null and unsafe types.Anonymous
August 09, 2007
I am wondering why a type used in a collection initializer must implement IEnumerable. It makes things just more complicated.Anonymous
August 11, 2007
Ok, so after being published on the VS Start Page on Aug-9th, how can we submit feedback?!Anonymous
August 11, 2007
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.Anonymous
August 12, 2007
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.)Anonymous
August 13, 2007
The comment has been removedAnonymous
August 13, 2007
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!) JonAnonymous
August 13, 2007
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.Anonymous
August 13, 2007
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.Anonymous
August 14, 2007
The new language extensions don't appear to have made it into the grammar in the appendices.Anonymous
August 15, 2007
After reading this i am very thankful to Microsoft team to provide us such a best collection.Anonymous
August 16, 2007
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