dotnet/csharplang: Where C# Language Features Are Designed Before They Ship

What dotnet/csharplang Is For, and Who It Is Not For

The README opens with a plain statement of scope: this is the official repo for C# language design, where new features are developed, adopted and specified. That sentence separates it from every other C# repository you might clone. Roslyn implements the language. dotnet/csharplang decides what the language should be, records the arguments, and writes the specification that Roslyn then has to satisfy.

The audience follows from that. If you are choosing a JSON library, this repo will not help. If you are trying to understand why a feature you expected in the next C# version is missing, or why a syntax you dislike exists, the meetings folder and the proposals folder are where the reasoning is written down. Compiler authors, framework maintainers, tooling vendors and people who write analyzers all have a stake in reading it, because a language change moves the ground under their code.

The README also draws a line that surprises newcomers. New feature proposals should be raised for discussion, and a proposal should only be submitted as an issue or pull request if a member of the Language Design Team invites it. That is not a formality. It means the repository is not an open suggestion box, and the contribution path is deliberately narrow.

How a Feature Moves From Discussion to Specification

The mechanism is a pipeline, and the repository layout mirrors it. Debate happens in GitHub Discussions. When a member of the C# Language Design Team (LDT) judges that a proposal deserves broader consideration, they champion it, which means they will bring it to a Language Design Meeting. Champion issues are locked against new discussion and carry a link to the discussion where the argument actually takes place, a policy the README admits was adopted late, so older champion issues still have comments on them.

Proposals then evolve through decisions in Language Design Meetings, informed by discussions, experiments and offline design work. The README is explicit that a prototype is often necessary before a design can be settled, and it sets a bar for one: implemented in a fork of Roslyn, parsing resilient enough that typing does not crash, minimal end-to-end tests, and minimal IDE support such as keyword coloring, formatting and completion. That bar is worth noting, because it means a feature can be rejected on evidence rather than on taste.

Once approved, the feature is fully implemented in Roslyn and fully specified in the spec folder, and the proposal moves into a folder for a completed feature. The data flow is therefore one direction: discussion feeds design meetings, design meetings feed the proposal text, the proposal text feeds the specification, and the specification governs the compiler.

Milestones Decide Whether a Proposal Is Coming or Going

The most useful part of the repository for planning is the milestone structure, and it is easy to misread. Working Set holds championed proposals currently being worked on, and the README states plainly that not everything in that milestone will make the next version of C#. Backlog holds triaged proposals that are not being actively worked on, where the design and implementation review cost is too high to accept community implementation yet. Any Time holds triaged proposals open to community implementation, split between those needing an approved specification and those needing implementation. Likely Never holds proposals the LDM has rejected, which will not be reconsidered without strong need or community feedback.

Numbered milestones are different in kind. They are the features implemented for a particular language version. For closed milestones that means what shipped; for open milestones, features can still be pulled if compatibility or other issues appear near release. So a numbered milestone is a shipping list under revision, not a contract.

Read together, these milestones answer the question engineers actually ask: is this feature worth designing around? A proposal in Working Set is a candidate. A proposal in Likely Never is a dead end unless the feedback changes. Neither is a commitment, and the README's disclaimer says so directly: an active proposal is under active consideration but is not guaranteed to be included in any version of the language.

Reading the Repo: A First Real Use

There is nothing to install. The repository is a collection of Markdown documents, and the README points to the proposals folder for active proposals, the meetings folder for design meeting notes organized by year, and Language-Version-History.md for the version history. The README does not give any clone or setup command, so the first use is simply to open those folders on GitHub and read the documents that matter to you.

The practical question a newcomer brings is whether a feature they read about is actually specified or merely proposed. The answer is in the path. A proposal filed under a versioned folder such as proposals/csharp-7.1, the example the README gives for a completed feature, has already been implemented and specified. A proposal sitting directly in the proposals folder is still active.

The README also notes that the lifetime of a design meeting note is described in meetings/README.md, so check that file before treating a note as a final decision. Read them for the reasoning, not for the final wording.

The Rules That Keep the Language From Growing Without Limit

One policy in the README is a genuine design constraint rather than housekeeping. Proposals that only make existing syntax optionally illegal will be rejected by the language design committee, to prevent increased language complexity. The README points out that such restrictions can be achieved with a Roslyn analyzer instead. That is a real division of labour: the compiler team refuses to spend language surface on rules that a linter can enforce per project.

The cost of that policy is that some teams will not get the enforcement they want from the language itself. If your organisation wants a construct banned, the answer from this repository is an analyzer, and the analyzer has to be configured and maintained by you. The benefit is that C# does not accumulate optional-illegal modes that every reader of the language has to learn about.

The discussion rules carry a similar tone. Off-topic discussion is closed summarily, comments should be useful to others rather than a fiftieth reply, and tangential points should become their own discussion with a link back. The README even asks whether a comment could be an emoji reaction instead. This is a repository that treats attention as a scarce resource, and it reads that way.

Where csharplang Is the Wrong Place to Look

The clearest failure mode is expecting implementation. Nothing here compiles your code. There is no package, no CLI, no runtime artifact. If you arrived looking for a C# library or a download, you are in the wrong repository, and the README will not redirect you to one; it points to Roslyn for implementation and to the specification for the normative text.

The second failure mode is treating a proposal as a roadmap. The disclaimer is unambiguous that a proposal may be postponed or rejected at any time based on feedback from the design team, community, code reviewers or testing. A team that plans a migration around a Working Set item is planning around a document that can change status without notice.

The third is trying to contribute a feature directly. The README asks for discussion first and reserves proposal submission for people invited by a champion. A well-argued pull request that arrives without that invitation is not following the process the repository describes, however good the idea is.

Roslyn is the natural counterpart here, and the difference is one of role rather than competition. Roslyn is the compiler and the implementation surface, where a feature exists in code and can be tried. csharplang is the design record, where the feature exists as an argument and a specification. If you want to know how a feature behaves today, read Roslyn. If you want to know why it behaves that way, or what might replace it, read csharplang.

Maintenance, Licence and What to Verify Before Depending on It

The repository is not archived, and the last push was on 2026-10-31. The design record is current. That says nothing about whether any individual proposal will ship, only that the pipeline is running.

There are no published GitHub releases, which is consistent with what the repository is: a document set rather than a versioned artifact. Upgrading means pulling the default branch and re-reading the proposals and meeting notes that changed, which is cheap in bandwidth and expensive in attention. There is no changelog to scan, so the practical approach is to watch the specific champion issues you care about rather than the repository as a whole.

GitHub does not identify a licence for the repository and no LICENSE file appears at the top level, so confirm the licence terms before reusing specification text or meeting notes in your own documentation. The README does not document rollback, and there is nothing to roll back to in the usual sense, since you are reading documents rather than running code. The one thing worth verifying first is the milestone on any proposal you intend to rely on, because that is the only signal in the repository about whether a feature is being worked on, waiting, open to community implementation, or rejected.

Editorial conclusion

Adopt dotnet/csharplang as a reading habit if you ship C# and need to know what is coming, or if you want to argue about a feature before it ships. Do not treat it as an installable library, and do not open a proposal issue unless a Language Design Team member champions it. Before relying on anything you read there, check the milestone on the champion issue and the folder the proposal sits in, because a proposal in the Working Set carries no guarantee of shipping in the next language version.

Frequently asked questions

Official sources

1. dotnet/csharplang on GitHub
2. Issues
3. README