The official repo for the design of the C# programming language
Перейти к файлу
NetMage 8cb28ad560
Update LDM-2020-05-27.md (#3875)
Replaced incorrect structs with classes in: "less far behind" than structs in record features
2020-09-10 18:56:10 -07:00
.github/ISSUE_TEMPLATE Add issue templates (#3872) 2020-09-10 09:54:59 -07:00
meetings Update LDM-2020-05-27.md (#3875) 2020-09-10 18:56:10 -07:00
proposals Grammar fixes (#3827) 2020-09-10 09:57:50 -07:00
spec Update unsafe-code.md 2020-07-16 14:14:04 +06:00
.gitattributes Add initial .gitattributes 2017-02-01 22:51:37 -06:00
.gitignore Move C# 7.1 proposals to 7.1 folder (#870) 2017-09-06 13:10:02 -07:00
CODE-OF-CONDUCT.md Link Code of Conduct 2020-04-02 13:42:06 -07:00
Communities.md Update communities and readme with links to the dotnet evolution discord. 2020-08-10 10:02:21 -07:00
Language-Version-History.md Document features shipping in C# 9.0 (#3850) 2020-09-08 11:17:39 -07:00
README.md Add Discussions guidance 2020-09-08 10:17:00 -07:00

README.md

C# Language Design

Join the chat at https://gitter.im/dotnet/csharplang Chat on Discord

Welcome to the official repo for C# language design. This is where new C# language features are developed, adopted and specified.

C# is designed by the C# Language Design Team (LDT) in close coordination with the Roslyn project, which implements the language.

You can find:

If you discover bugs or deficiencies in the above, please leave an issue to raise them, or even better: a pull request to fix them.

For new feature proposals, however, please raise them for discussion, and only submit a proposal as a pull request if invited to do so by a member of the Language Design Team (a "champion").

Discussions

Debate pertaining to language features takes place in the form of Discussions in this repo.

If you want to suggest a feature, discuss current design notes or proposals, etc., please open a new Discussion topic.

Discussions that are short and stay on topic are much more likely to be read. If you leave comment number fifty, chances are that only a few people will read it. To make discussions easier to navigate and benefit from, please observe a few rules of thumb:

  • Discussion should be relevant to C# language design. If they are not, they will be summarily closed.
  • Choose a descriptive topic that clearly communicates the scope of discussion.
  • Stick to the topic of the discussion. If a comment is tangential, or goes into detail on a subtopic, start a new discussion and link back.
  • Is your comment useful for others to read, or can it be adequately expressed with an emoji reaction to an existing comment?

Proposals

Once you have a fully fleshed out proposal describing a new language feature in syntactic and semantic detail, please open an issue for it, and it will be labeled as a Proposal. The comment thread on the issue can be used to hash out or briefly discuss details of the proposal, as well as pros and cons of adopting it into C#. If an issue does not meet the bar of being a full proposal, we may move it to a discussion, so that it can be "baked" further. Specific open issues or more expansive discussion with a proposal will often warrant opening a side discussion rather than cluttering the comment section on the issue.

When a member of the C# LDM finds that a proposal merits discussion, they can Champion it, which means that they will bring it to the C# Language Design Meeting. If the LDM decides to work on adopting the feature, the proposer, the champion and others can collaborate on adding it as a document to the Proposals folder, where its evolution can be tracked over time.

Design Process

Proposals evolve as a result of decisions in Language Design Meetings, which are informed by discussions, experiments, and offline design work.

In many cases it will be necessary to implement and share a prototype of a feature in order to land on the right design, and ultimately decide whether to adopt the feature. Prototypes help discover both implementation and usability issues of a feature. A prototype should be implemented in a fork of the Roslyn repo and meet the following bar:

  • Parsing (if applicable) should be resilient to experimentation: typing should not cause crashes.
  • Include minimal tests demonstrating the feature at work end-to-end.
  • Include minimal IDE support (keyword coloring, formatting, completion).

Once approved, a feature should be fully implemented in Roslyn, and fully specified in the language specification, whereupon the proposal is moved into the appropriate folder for a completed feature, e.g. C# 7.1 proposals.

DISCLAIMER: An active proposal is under active consideration for inclusion into a future version of the C# programming language but is not in any way guaranteed to ultimately be included in the next or any version of the language. A proposal may be postponed or rejected at any time during any phase of the above process based on feedback from the design team, community, code reviewers, or testing.

Language Design Meetings

Language Design Meetings (LDMs) are held by the LDT and occasional invited guests, and are documented in Design Meeting Notes in the meetings folder, organized in folders by year. The lifetime of a design meeting note is described in meetings/README.md. LDMs are where decisions about future C# versions are made, including which proposals to work on, how to evolve the proposals, and whether and when to adopt them.

Language Specification

It is our plan to move the C# Language Specification into Markdown, and draft it in the spec folder. The spec drafts will eventually be standardized and published by ECMA. The folder currently contains an unofficial Markdown version of the C# 6.0 specification for convenience.

Implementation

The reference implementation of the C# language can be found in the Roslyn repository. This repository also tracks the implementation status for language features. Until recently, that was also where language design artifacts were tracked. Please allow a little time as we move over active proposals.