Announcing Open Source C# standardization

Bill Wagner

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.

Welcome dotnet/csharpstandard

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:

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:

You can participate by reviewing the PRs, opening issues for changes that aren’t covered, and helping refine the language in PRs.

Thank you

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.


Discussion is closed. Login to edit/delete existing comments.

  • Mason Wheeler 0

    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.

    • Ladislav Burkovsky 0

      Definitely agree. If possible avoid silos and enable community to develop special need solutions.

    • Lukas Novotny 0

      Absolutely agree, CLR is long overdue for evolution.

  • Akmal Kamalov 0

    Glad to hear this 🙂

  • Christophe Pichaud 0

    CsharpStandard is a very very bad marketing name.


    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 with folders:
    – compilers
    – clr
    – bcl
    – shared modules
    – docs
    – specifications

    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…

    Christophe Pichaud
    AIDE-MÉMOIRE C# / .NET5, Dunod, Jan 2021
    6 Books published on Amazon

    CEO NET Azure Rangers LLC
    France, UK, USA |

    • Maximilien Noal 0

      What is so hard to understand ?

      • Paulius P 0

        Is this Microsoft Marketing Department asking?

        • Maximilien Noal 0

          No… ?

    • Matthijs Wensveen 0

      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.

    • Daniel Smith 0

      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.

  • Stevie White (Dragnilar) 0

    Two things…

    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:

  • David Merritt 0

    Glad to hear as well!!!

  • Ken Domino 0

    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, 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.

    • Bill WagnerMicrosoft employee 0


      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-v6 branch 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 spec folder 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 draft-v7 branch.

      We’d like to be in a better place, and we’ll get there. We’re just not there yet.

Feedback usabilla icon