Skip to content
Branch: master
Find file History
agocke Add spec work for record ctor (#3076)
* Add spec work for record ctor

* Add more detail about constructor implementation
Latest commit e134bb7 Jan 16, 2020
Permalink
Type Name Latest commit message Commit time
..
Failed to load latest commit information.
csharp-7.0 Fix broken links (#3091) Jan 14, 2020
csharp-7.1 Update target-typed-default.md Jul 30, 2019
csharp-7.2 Fix broken links (#3091) Jan 14, 2020
csharp-7.3 markdown fixes for 7.3 proposals Mar 7, 2019
csharp-8.0 Fix broken links (#3091) Jan 14, 2020
inactive Add folders and READMEs Jan 27, 2017
rejected Add folders and READMEs Jan 27, 2017
README.md Update READMEs for discussion in GitHub issues Feb 14, 2017
caller-argument-expression.md markdown fixes Mar 7, 2019
covariant-returns.md markdown fixes Mar 7, 2019
declaration-expressions.md
discriminated-unions.md Add proposal for discriminated unions Nov 15, 2019
fixed-sized-buffers.md markdown fixes Mar 7, 2019
format.md Fix typos in format proposal Apr 4, 2019
function-pointers.md Update function pointer proposal with LDM changes (#2923) Nov 18, 2019
intptr-operators.md markdown fixes Mar 7, 2019
intrinsics.md Fixed typos (#2167) Feb 12, 2019
lambda-attributes.md markdown fixes Mar 7, 2019
lambda-discard-parameters.md Create speclet for lambda discard parameters (#2901) Dec 13, 2019
null-arg-checking.md Fixed typos (#2167) Feb 12, 2019
null-conditional-await.md markdown fixes Mar 7, 2019
nullable-enhanced-common-type.md Add support for common type of `int` and `double?`. (#1806) Sep 6, 2018
primary-constructors.md Create primary-constructors.md Jul 23, 2019
proposal-template.md Remove abbreviations from the text (#68) Feb 13, 2017
readonly-locals.md fix formatting Mar 7, 2019
records-wip.md Add spec work for record ctor (#3076) Jan 16, 2020
records.md typo: Double word "the" Apr 13, 2019
recordsv2.md Update recordsv2.md (#2717) Aug 8, 2019
skip-localsinit.md Fixed typos (#2167) Feb 12, 2019
static-delegates.md Fixed typos (#2167) Feb 12, 2019
static-lambdas.md Create static-lambdas.md (#2899) Oct 22, 2019
target-typed-new.md Fixed typos (#2167) Feb 12, 2019

README.md

C# Language Proposals

Language proposals are living documents describing the current thinking about a given language feature.

Proposals can be either active, inactive, rejected or done. Active proposals are stored directly in the proposals folder, inactive and rejected proposals are stored in the inactive and rejected subfolders, and done proposals are archived in a folder corresponding to the language version they are part of.

Lifetime of a proposal

A proposal starts its life when the language design team decides that it might make a good addition to the language some day. Typically it will start out being active, but if we want to capture an idea without wanting to work on it right now, a proposal can also start out in the inactive subfolder. Proposals may even start out directly in the rejected state, if we want to make a record of something we don't intend to do. For instance, if a popular and recurring request is not possible to implement, we can capture that as a rejected proposal.

The proposal may start out as an idea in a discussion issue, or it may come from discussions in the Language Design Meeting, or arrive from many other fronts. The main thing is that the design team feels that it should be done, and that there's someone who is willing to write it up. Typically a member of the Language Design Team will assign themselves as a champion for the feature, tracked by a Champion issue. The champion is responsible for moving the proposal through the design process.

A proposal is active if it is moving forward through design and implementation toward an upcoming release. Once it is completely done, i.e. an implementation has been merged into a release and the feature has been specified, it is moved into a subdirectory corresponding to its release.

If a feature turns out not to be likely to make it into the language at all, e.g. because it proves unfeasible, does not seem to add enough value or just isn't right for the language, it will be rejected. If a feature has reasonable promise but is not currently being prioritized to work on, it may be declared inactive to avoid cluttering the main folder. It is perfectly fine for work to happen on inactive or rejected proposals, and for them to be resurrected later. The categories are there to reflect current design intent.

Nature of a proposal

A proposal should follow the proposal template. A good proposal should:

  • Fit with the general spirit and aesthetic of the language.
  • Not introduce subtly alternate syntax for existing features.
  • Add a lot of value for a clear set of users.
  • Not add significantly to the complexity of the language, especially for new users.

Discussion of proposals

Feedback and discussion happens in discussion issues. When a new proposal is added to the proposals folder, it should be announced in a discussion issue by the champion or proposal author.

You can’t perform that action at this time.