This site is for suggestions about the future evolution of the F# Language and Core Library. Please read about the F# Language and Core Library RFC Process. For discussions about tooling (editor support, compiler services etc.) please see http://fsharp.org/guides/engineering/issues.
Voting is by giving 👍 reactions to an issue.
The items marked approved-in-principle for F# 4.x or beyond, are eligible to be taken to an RFC. You can contribute detailed designs, implementation and testing for these items. See http://fsharp.github.io/2014/06/18/fsharp-contributions.html for information on contributing to the evolution of the F# Language Design and Core Library.
Please search for an existing suggestion before opening a new one. Just use GitHub search over the issues in this repository.
Create a new suggestion (have you searched for existing similar suggestions?)
We do not in general revisit design decisions that have already been decided. In particular there is a distinction between
- things we have previousy decided "not to do"
- things where we decided to do X, considered Y, and by doing X implicitly decided not to do Y
- things we thought about doing and left open the future possibility of doing them
- things we never thought of before
Most of the existing open suggestions are in category 3 or 4. In general things in categories 1 and 2 won't be reconsidered unless there is a really very strong case, e.g. because of a change in circumstance. Many suggestions will thus be closed with responses like "we considered this in F# 2.0 and decided against this". The design notes for F# 2.0-3.0 are only available in email form, we will gradually try to make them available from our archives.
The decisions about moving things to "approved in principle" (and thus RFC stage) are up to the language designer ("BDFL"), Don Syme. The votes are just used as an indicator. A huge range of factors go into the decision to "approve in principle", including:
- estimated utility
- estimated cost of implementing
- completeness of proposed design (is this an "idea" or a concrete suggestion)
- availability of alterenatives
- education/learning paths and simplicity
- does this give multiple ways to achieve the same thing
- votes
- design coherence
- "less is more" design considerations
- likelihood of breaking change
- strategic importance
- usefulness (or otherwise) for interop with .NET and other languages
- risk of churn w.r.t. bugs
- cost of churn w.r.t. education materials (new editions of books etc.)
- is someone stepping up to the plate to write an RFC, implement the change and own it long term?
Also we have a large queue of relatively small-cost "approved in principle" items, and a large (and occasionally growing) number of bugs/issues in http://github.com/Microsoft/visualfsharp. Getting through these is also a priority.
Adding endless new language features in every version has major downsides. Here are some observations on why adding features is not necessarily a good thing:
- Stability is a virtue
- Gradual evolution is good
- Adding new language features on every version is not a necessarily a sign of strength. Many languages have spread very widely while remaining very stable (e.g. Java in 2000-2013)
- The addition of new features on every version can be a sign that language implementors are being incentivized (e.g. getting paid) for feature-completion rather than overall simplicity and utility.
- New features add learning costs to every user of the language
In contrast, features which make the language more orthogonal, simpler and easier to use are generally a very good thing.
First make sure the issue for your feature is really clear and addresses all major concerns.
Probably the best thing you can do to get a feature promoted is to draft an RFC on it, even if it has not yet been marked "approved". A prototype implementation of high quality, with tests, can also help convince.