Skip to content
Permalink
main
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

fslang-design/RFC_template.md

Go to file
 
 
Cannot retrieve contributors at this time
F# RFC FS-NNNN - (Fill me in with a feature name) Summary Motivation Detailed design Drawbacks Alternatives Compatibility Pragmatics Diagnostics Tooling Performance Scaling Culture-aware formatting/parsing Unresolved questions
96 lines (59 sloc) 3.23 KB
Raw Blame
Open in GitHub Desktop

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.

Summary

One paragraph explanation of the feature.

Motivation

Why are we doing this? What use cases does it support? What is the expected outcome?

Detailed design

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.

Example code:

let add x y = x + y

Drawbacks

Why should we not do this?

Alternatives

What other designs have been considered? What is the impact of not doing this?

Compatibility

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?

Pragmatics

Diagnostics

Please list the reasonable expectations for diagnostics for misuse of this feature.

Tooling

Please list the reasonable expectations for tooling for this feature, including any of these:

  • Debugging
    • Breakpoints/stepping
    • Expression evaluator
    • Data displays for locals and hover tips
  • Auto-complete
  • Tooltips
  • Navigation and Go To Definition
  • Colorization
  • Brace/parenthesis matching

Performance

Please list any notable concerns for impact on the performance of compilation and/or generated code

  • For existing code
  • For the new features

Scaling

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.

For example

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

Culture-aware formatting/parsing

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.

Unresolved questions

What parts of the design are still TBD?