The place to make suggestions, discuss and vote on F# language and core library features
Switch branches/tags
Nothing to show
Clone or download
Latest commit 91f2d59 Mar 2, 2018
Failed to load latest commit information. Update Jun 19, 2017 Update (#649) Mar 3, 2018

Welcome to F# Language and Core Library Suggestions!

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

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

View all suggestions

View popular suggestions (votes by 👍)

View newest suggestions

View approved-in-principle suggestions

View started suggestions

View open suggestions (language)

View open suggestions (core library)

View completed suggestions

View declined suggestions

Create a new suggestion (have you searched for existing similar suggestions?)

Notes on the Design Process

We do not in general revisit design decisions that have already been decided. In particular there is a distinction between

  1. things we have previousy decided "not to do"
  2. things where we decided to do X, considered Y, and by doing X implicitly decided not to do Y
  3. things we thought about doing and left open the future possibility of doing them
  4. 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 Getting through these is also a priority.

When are new features a good thing?

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:

  1. Stability is a virtue
  2. Gradual evolution is good
  3. 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)
  4. 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.
  5. 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.

What about optional features?

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#).

How do I get my favourite feature approved?

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.