This repository is for suggestions about the future evolution of the F# Language and Core Library. For discussions about tooling (editor support, compiler services etc.) please see http://github.com/dotnet/fsharp.
Voting is by giving 👍 reactions to an issue.
The items marked approved-in-principle are eligible to be taken to an RFC in the F# language design repository. You can contribute an implementation for an RFC in the F# development repository.
Please search for an existing suggestion before opening a new one. Just use GitHub search over the issues in this repository.
(the comments from that time are linked but it got 404'ed)
(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 previously 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 alternatives
- education/learning paths and simplicity
- whether this gives 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.)
- whether someone is willing to step 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/dotnet/fsharp. 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.
There's a strong bias in the language design (and likewise in many other language designs) against optional features which effectively turn the language into a slightly different language ("bifurcate the language").
There are many social reasons for avoiding such optional features - e.g. when you code review code, or have two programmers meeting in a team and having to decide on standards - it's one thing to have to decide on coding conventions and design idioms, it's another to have to turn the knobs and dials on the language to select what's allowed.
For this reason making a feature optional will generally not used as an approach, though exceptions may be made in some cases (e.g. checked arithmetic is optional in both F# and C#).
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.
This repository is governed by the Contributor Covenant Code of Conduct.
We pledge to be overt in our openness, welcoming all people to contribute, and pledging in return to value them as whole human beings and to foster an atmosphere of kindness, cooperation, and understanding.
We additionally request that the use of the personal pronon "you" (referring to a specific person) should be minimized in discussions. The use of the word is common, and often doesn't refer to an individual, but an effort should please be made to make technical points in a non-personal way, addressing the technical matter, rather than the person. A simple technique is to draft your contribution and check for the number of uses of "you" and reduce out unnecessary uses. If an ad-hominem or otherwise overly personalized mode is used for technical argument the moderators may hide or delete these contributions, requesting that content be reposted without making arguments in this way.