Announcing Open Source C# standardization
The C# compilers have been open source since 2014, now in the dotnet/roslyn repository. The dotnet/csharplang split off to provide a dedicate public space for the innovation and evolution of the C# language. Now, dotnet/csharpstandard completes the group, providing a public space for the ongoing work to document the standard for the latest C# language versions.
Moving the standards work into the open, under the .NET Foundation, makes it easier for standardization work. Everything from language innovation and feature design through implementation and on to standardization now takes place in the open. It will be easier to ask questions among the language design team, the compiler implementers, and the standards committee. Even better, those conversations will be public.
The end result will be a more accurate standard for the latest versions of C#.
Opening the process
The ECMA C# standards committee, TC-49-TG2 is still responsible for creating the proposed standard for the C# language. What changes is that work now happens in the open, under the .NET Foundation. You can see work in progress on the standard text for C# 6. This work merges the draft spec currently hosted in the
csharplang repository with the current C# 5.0 standard text. Work on incorporating the C# 7 features is taking place as well. See the C# 7 draft branch for progress.
The addition of
dotnet/csharpstandard means there are now three different repositories related to the C# language. Each has a well-defined purpose:
dotnet/csharplangis for language design and evolution efforts.
dotnet/roslynis for the implementation of the compilers and related tools.
dotnet/csharpstandardis for the creation of the standard text that describes the C# language.
The addition of
dotnet/csharpstandard to the .NET Foundation means we can direct work to the correct place more easily. You’ll see the following changes over the coming months:
- Issues in
dotnet/docsfor the spec text will move to the new
- This will take place during the next month or two.
- The C# spec on docs.microsoft.com will be replaced with the version from the standards committee.
- This will take place once all C# 6 pull requests have been reviewed and merged in the standards repo.
- The C# 6 draft spec will be removed from the
- This will take place once the proposed C# 6 draft is published on docs.microsoft.com.
You can participate by reviewing the PRs, opening issues for changes that aren’t covered, and helping refine the language in PRs.
Moving the standards work into a public repository took the cooperation of the members of the C# standards committee, the chair, vice-chair and secretary of ECMA TG49, and the .NET Foundation board. We invite you to participate by identifying issues, reviewing proposed text, and suggesting improvements. We’re excited to move this work into the open, and invite all of you along.
Are there any comparable efforts to allow the community to help update the CLR standard definitions? So much of the work that has gone into updating the C# language, and the work that is continuing to be put into evolving it, would be significantly easier if we weren’t still locked into the restrictive CLR 2.0 IL and metadata architecture.
Look at the insane mass of complexity and gibberish that is the current proposal for “shapes,” which will only be available to one CLR language (C#) even though, once it’s implemented, it’s virtually certain to start showing up in APIs throughout the NuGet ecosystem, disadvantaging users of any other language. And all because we have no standardized way of expressing additional types of generic constraints in the CLR type system.
Look at how much work every single CLR language has to put in to create iterator and async state machines, all because there’s no way to express the concept of a “coroutine” directly at the IL level. (Or a “closure” for that matter!)
Look at the massive, confusing mess that is NRTs because there’s no way to encode the concept of “non-nullable reference type” in the CLR type system.
The CLR 2.0 IL instruction set and metadata/type system were great back in 2006, but the architecture has been showing its age for years now. It’s long since time we evolved it to better meet modern needs, rather than shoving everything into Roslyn, piling hack upon hack upon hack in the C# compiler and leaving the rest of the CLR ecosystem behind. The C in CLR stands for “Common,” not “C#”. It’s time we recognize this fact and broaden the common base to include concepts that have become so common as to be indispensable over the last 15 years.
Definitely agree. If possible avoid silos and enable community to develop special need solutions.
Absolutely agree, CLR is long overdue for evolution.
Glad to hear this 🙂
CsharpStandard is a very very bad marketing name.
It’s like netstandard: NOBODY UNDERSTAND WHAT IS THE DIFFERENCE BETWEEN NET .NET CORE 2.0 3.1 .NET STANDARD 1 2 ….ETC.
Before trying to always make a triple axel and trying to not fall on the ice like an arrogant champion ice dance, please associates real developers and architects to all the naming décisions made by the F***ing Marketing Department.
The naming convention for NET since .NET Standard and .NET CORE is a massive failure and the names of the repos in GitHub are changing every 2 years….
It’s so simple to have GitHub.com/Microsoft/NET with folders:
– shared modules
Microsoft Marketing Department is a place of little barons.
I am in .NET since march 2001, Develop Mentor Conference.NET conference organized with Microsoft Teams that were presenting all .NET and CLR and BCL ASP.NET, WinForms and Web Services for .NET SZdK Beta 2…
AIDE-MÉMOIRE C# / .NET5, Dunod, Jan 2021
6 Books published on Amazon
CEO NET Azure Rangers LLC
France, UK, USA
http://www.windowscpp.com | http://www.christophep.com
What is so hard to understand ?
Is this Microsoft Marketing Department asking?
This announcement is about the C# language specification and the ECMA standard that describes it (ECMA-334). This has little to do with the products .NET standard/core/etc., except that they both contain the word “standard” with different meanings.
Are you crazy Christophe? You want them to put the compilers in a “compilers” folder, the docs in a “docs” folder, and the specs in a “specs” folder? Oh wait, that’s entirely sensible! Come on Microsoft, you know this makes much more sense.
First – Bill, I don’t like your profile photo.
Second – I really am skeptical and think this is Microsoft playing catch up with Oracle on Java. :-/
Edit: Old article about this if anyone cares to read it: https://www.zdnet.com/article/what-is-ecma-and-why-microsoft-cares/
Glad to hear as well!!!
Documenting the language is welcome news. However, I don’t understand the difference in purpose between csharplang and csharpstandard. At face value, the repositories appear to have similar content. For example, both describe the C# language. Both have documentation for expressions, here and here. Both are marked version 6. But, between these repositories, expressions.md differ significantly, not just in markdown formatting, but in content. Which is more up-to-date on describing version 6? Currently, C# is at version 8, with soon-to-be version 9, I presume in November ’21. Where is that documented? I am still at a loss: it makes it hard for language tool makers, such as myself, to develop a tool that works with a specific version of the language. That is why I am writing a tool to scrape the CFG language directly from the recursive descent implementation source.
We are working on fixing this situation. The reason csharplang and csharpstandard have different text is because of the way the C# spec documents diverged while the standardization process was dormant between V2 and V5.
Right now: csharplang’s main branch more accurately has all of V6. csharpstandard has PRs that will bring them together. The
draft-v6branch has our current working draft for V6. We haven’t finished all the features yet.
We’re working hard to catch up, but it will take time.
My recommendation: chsharpstandard is more accurate, but farther behind. As the committee catches up, we’ll remove the
specfolder from csharplang. Until we get to C# 7 and beyond, the proposals folder in csharplang is the closest we have. We have PRs for some of the features in the csharpstandard repo, targeting the
We’d like to be in a better place, and we’ll get there. We’re just not there yet.