F# RFC FS-NNNN - (Fill me in with a feature name)
NOTE: new sections have been added to this template! Please use this template rather than copying an existing RFC.
The design suggestion FILL ME IN has been marked "approved in principle".
This RFC covers the detailed proposal for this suggestion.
- Approved in principle
- Design Review Meeting(s) with @dsyme and others invitees
One paragraph explanation of the feature.
Why are we doing this? What use cases does it support? What is the expected outcome?
This is the bulk of the RFC. Explain the design in enough detail for somebody familiar with the language to understand, and for somebody familiar with the compiler to implement. This should get into specifics and corner-cases, and include examples of how the feature is used.
let add x y = x + y
Why should we not do this?
What other designs have been considered? What is the impact of not doing this?
Please address all necessary compatibility questions:
- Is this a breaking change?
- What happens when previous versions of the F# compiler encounter this design addition as source code?
- What happens when previous versions of the F# compiler encounter this design addition in compiled binaries?
- If this is a change or extension to FSharp.Core, what happens when previous versions of the F# compiler encounter this construct?
Please list the reasonable expectations for diagnostics for misuse of this feature.
Please list the reasonable expectations for tooling for this feature, including any of these:
- Expression evaluator
- Data displays for locals and hover tips
- Navigation and Go To Definition
- Brace/parenthesis matching
Please list any notable concerns for impact on the performance of compilation and/or generated code
- For existing code
- For the new features
Please list the dimensions that describe the inputs for this new feature, e.g. "number of widgets" etc. For each, estimate a reasonable upper bound for the expected size in human-written code and machine-generated code that the compiler will accept.
- Expected maximum number of widgets in reasonable hand-written code: 100
- Expected reasonable upper bound for number of widgets accepted: 500
Testing should particularly check that compilation is linear (or log-linear or similar) along these dimensions. If quadratic or worse this should ideally be noted in the RFC.
Does the proposed RFC interact with culture-aware formatting and parsing of numbers, dates and currencies? For example, if the RFC includes plaintext outputs, are these outputs specified to be culture-invariant or current-culture.
What parts of the design are still TBD?