F# Language

This User Voice 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://fsharp.org/guides/engineering/issues.

The items “approved-in-principle” by for F# 4.x or beyond are listed at http://fslang.uservoice.com/forums/245727-f-language/status/1225914. 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.

I suggest we ...

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

  • When an admin closes an idea you've voted on, you'll get your votes back from that idea.
  • You can remove your votes from an open idea you support.
  • To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".
(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

  1. Allow lower-case DU cases when [<RequireQualifiedAccess>] is specified

    Currently, it is not allowed to declare DU cases with lower-case letters. For instance, this is not allowed:

    type Foo =
    | foo
    | bar
    | baz
    // etc...

    This yields: error FS0053: Discriminated union cases and exception labels must be uppercase identifiers

    As I understand it, this is to prevent ambiguity in pattern matching between matching a union case and binding to an identifier. However, this is not an issue if the [<RequireQualifiedAccess>] attribute is specified on the DU. Therefore, I propose we allow lower-case cases in this case.

    1 vote
    Vote
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      You have left! (?) (thinking…)
    • Relax indentation rules on Records

      The current indentation rules around records seem inconsistent, or at least counter-intuitive. Consider for instance:

      type Foo = {
      ....Foo:int
      ....}

      type Bar = {
      ....F:Foo
      ....}

      let bar = {
      ....F = {
      ........Foo = 10
      ........}
      ....}

      This is valid. But if you change F in Bar to VeryLongName:

      type Baz = {
      ....VeryLongName:Foo
      ....}

      let baz = {
      ....VeryLongName = {
      ........Foo = 10
      ........}
      ....}

      We now get a warning:
      warning FS0058: Possible incorrect indentation: this token is offside of context started at position (10:20). Try indenting this token further or using standard formatting conventions.

      In…

      5 votes
      Vote
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        I agree to the terms of service
        Signed in as (Sign out)
        You have left! (?) (thinking…)
      • Literal sprintf

        Allow:
        ```
        [<Literal>]
        let a = sprintf "%s" "string"
        ```

        10 votes
        Vote
        Sign in
        Check!
        (thinking…)
        Reset
        or sign in with
        • facebook
        • google
          Password icon
          I agree to the terms of service
          Signed in as (Sign out)
          You have left! (?) (thinking…)
        • Support isNull when querying the built-in SQL type providers

          Right now the query expression-to-LINQ translation doesn't support queries such as `query { for x in table do where (isNull x.Field) }`. Instead we have to use `where (x.Field = null)`. That's quite inconsistent: in normal (non-query) code, `isNull` is advised, but in query code, we can't use it.

          7 votes
          Vote
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            I agree to the terms of service
            Signed in as (Sign out)
            You have left! (?) (thinking…)
            1 comment  ·  Admin →
          • Have TypeProviderConfig.IsHostedExecution = true for type providers instantiated in *.fsx files

            Have TypeProviderConfig.IsHostedExecution = true for type providers instantiated in *.fsx files

            This came up in my work on FSharp.Data.SqlClient library.
            Up until version 1.8.2 version of the library SqlCommandProvider provided command types with two constructors of following signatures:
            new: connectionString: string, ?commandTimeout: int
            new: ?connection: SqlConnection, ?transaction: SqlTransactoin, ?commandTimeout: int
            Keep in mind that above are not normal F# type signatures but rather signature as suggested by Intellisense otherwise parameters with default values won’t show as optional.
            It allowed to write following code:
            do
            use cmd = new SqlCommandProvider<"SELECT 42", "Server=.;Integrated Security=true">()
            cmd.Execute()
            It resolves to second constructor invocation where…

            7 votes
            Vote
            Sign in
            Check!
            (thinking…)
            Reset
            or sign in with
            • facebook
            • google
              Password icon
              I agree to the terms of service
              Signed in as (Sign out)
              You have left! (?) (thinking…)
            • Add a warning for new keyword used on types which are not IDisposable

              This is an alternative to: https://fslang.uservoice.com/forums/245727-f-language/suggestions/15257796-remove-warning-for-new-keyword-on-idisposable

              The idea is that the new keyword provides valuable information, but only if you do not use it on all types.

              When avoiding its usage, you get a visual clue as to instances of disposable types, as well as warnings if you bind them.

              By making it a warning to use new unnecessarily, the compiler would effectively enforce a "best practice" with regards to IDisposable usage. It goes a long way today, but requires discipline to make it useful.

              This would be especially helpful to people coming to F# from C#, as many immediately…

              16 votes
              Vote
              Sign in
              Check!
              (thinking…)
              Reset
              or sign in with
              • facebook
              • google
                Password icon
                I agree to the terms of service
                Signed in as (Sign out)
                You have left! (?) (thinking…)
              • allow compiler directive to switch off inlining

                to get around debugging issues with the inline macro device, this pattern creaps into the code base (taken from FsPickler):

                #if DEBUG
                let writeBoundedSequence
                #else
                let inline writeBoundedSequence
                #endif

                It would be nice to be able to turn off the effect of the inline keyword for files and entire projects while compiling for debugging purposes. Also, optionally setting ignore inline for code executed in an interactive session would be useful too.

                5 votes
                Vote
                Sign in
                Check!
                (thinking…)
                Reset
                or sign in with
                • facebook
                • google
                  Password icon
                  I agree to the terms of service
                  Signed in as (Sign out)
                  You have left! (?) (thinking…)
                • Remove warning for new keyword on IDisposable

                  The only time I ever use the new keyword is on Disposables, and even then only to silence the compiler warnings. I'm not sure what purpose the warning serves either, because you can still forget to bind the disposable with the use keyword instead of with let. What's more annoying is that it prevents you from effective pipelining.

                  Could this be removed from the next F# release, or perhaps replaced with a warning if you bind a Disposable with let instead of use?

                  5 votes
                  Vote
                  Sign in
                  Check!
                  (thinking…)
                  Reset
                  or sign in with
                  • facebook
                  • google
                    Password icon
                    I agree to the terms of service
                    Signed in as (Sign out)
                    You have left! (?) (thinking…)
                  • Return untyped syntax tree from ITypeProvider

                    Add the ability to *opt in* to send back an untyped syntax tree from ITypeProviders. The current type provider mechanism is good for simple data exploration use cases, but otherwise extremely limited, and will soon allow for less metaprogramming than Roslyn in some ways. Currently, some types of type providers not possible to create, because unbound generics, records, discriminated unions, and other normal language features are not supported.

                    With the ability to opt in to just returning an untyped syntax tree, it would enable the creation of just about any type provider. It would also effectively give F# macros, though…

                    24 votes
                    Vote
                    Sign in
                    Check!
                    (thinking…)
                    Reset
                    or sign in with
                    • facebook
                    • google
                      Password icon
                      I agree to the terms of service
                      Signed in as (Sign out)
                      You have left! (?) (thinking…)
                    • Multi-case unions compiled to struct

                      I am posting this idea to be able to track its status since it is already informally under consideration. Tuples, records, and single-cases unions are have already planned (implementation even nearing completoin) to be compilable to a struct:

                      struct tuples: https://fslang.uservoice.com/forums/245727-f-language/suggestions/6148669-add-support-for-structtuple
                      struct records: https://fslang.uservoice.com/forums/245727-f-language/suggestions/6547517-record-types-can-be-marked-with-the-struct-attribu
                      struct single-case unions: https://fslang.uservoice.com/forums/245727-f-language/suggestions/6147144-allow-single-case-unions-to-be-compiled-as-structs

                      There is also already a proof of concept for unions of "blittable" types: https://fslang.uservoice.com/forums/245727-f-language/suggestions/7072844-utilise-clr-union-types-for-discriminated-unions

                      There has also been a lot of discussion on the implementation of multi-case unions in the discussion of struct records: https://github.com/Microsoft/visualfsharp/pull/620

                      One great use of multi-case unions compiled to struct would be optional computations (e.g. Option<'T>) for value…

                      20 votes
                      Vote
                      Sign in
                      Check!
                      (thinking…)
                      Reset
                      or sign in with
                      • facebook
                      • google
                        Password icon
                        I agree to the terms of service
                        Signed in as (Sign out)
                        You have left! (?) (thinking…)
                      • Nominal subtyping of unions

                        This is basically a repost of "subtyping for discriminated unions" (https://fslang.uservoice.com/forums/245727-f-language/suggestions/6672490-subtyping-for-discriminated-unions), but with more details and a description of a concrete use case.

                        I am reposting because I would like more discussion on this and because I think that declined requests are no longer tracked by Don Syme (and others).

                        Don Syme declined the feature because he likes features to be generic and symmetric for types in F#. This is a good general rule and I trust in Don's good taste, but I think that this feature request is an exception to the rule, so the decline should…

                        7 votes
                        Vote
                        Sign in
                        Check!
                        (thinking…)
                        Reset
                        or sign in with
                        • facebook
                        • google
                          Password icon
                          I agree to the terms of service
                          Signed in as (Sign out)
                          You have left! (?) (thinking…)
                        • Support constant values in Discriminated unions

                          Hi,

                          While trying to model a music domain I ended up with this code:

                          type Note = | C | CSharp | DFlat | D | DSharp | EFlat | E | F | FSharp
                          | GFlat | G | GSharp | AFlat | A | ASharp | BFlat | B

                          let noteName note =
                          match note with
                          | C -> "C" | CSharp -> "C#" | DFlat -> "Db" | D -> "D"
                          | DSharp -> "D#" | EFlat -> "Eb" | E -> "E" | F -> "F"
                          | FSharp -> "F#" | GFlat -> "Gb" | G…

                          5 votes
                          Vote
                          Sign in
                          Check!
                          (thinking…)
                          Reset
                          or sign in with
                          • facebook
                          • google
                            Password icon
                            I agree to the terms of service
                            Signed in as (Sign out)
                            You have left! (?) (thinking…)
                          • Support mixed F# and C# projects in order to extend F# usage

                            Support mixing F# and C# source files in the same project in order to support a gradual move to F# for new users/organisations and to support cases where tooling is oriented at C# (F# not supported)

                            For instance I could use this feature to slowly move a C# project to F# one class at the time. Another example would be to use C# tooling to generate web infrastructure like ASP.NET 5 controllers (because F# does not currently have templates for this) and then call directly into F# from those.

                            P.S. Other languages that F# compares to like Scala already supported…

                            106 votes
                            Vote
                            Sign in
                            Check!
                            (thinking…)
                            Reset
                            or sign in with
                            • facebook
                            • google
                              Password icon
                              I agree to the terms of service
                              Signed in as (Sign out)
                              You have left! (?) (thinking…)
                            • kprintf with delayed string construction

                              Currently kprintf and friends take in a continuation function and a StringFormat and return a curried function that when applied builds the string.

                              It would be nice for logging frameworks to have an overload where the continuation does not build the string rather provides a delayed function to build the string.

                              That way I can do something like:
                              let public logWithFormat logLevel logFormat =
                              kprintf (fun stringBuilder -> if logLevel > currentLoggingLevel then sprintf "%s" (stringBuilder())) logFormat

                              7 votes
                              Vote
                              Sign in
                              Check!
                              (thinking…)
                              Reset
                              or sign in with
                              • facebook
                              • google
                                Password icon
                                I agree to the terms of service
                                Signed in as (Sign out)
                                You have left! (?) (thinking…)
                              • Provide property on base Discriminated Union type if all the case constructors have the same paramater

                                If an each case constructor of Discriminated Union has a parameter with the same name and the same type than allow to implement a property on Discriminated Union base type to access to this parameter value.

                                Now I have to write a match on every case

                                type Physical =
                                | OneToOne of Data : ModuleData * Line : ModuleList
                                | OneOnOne of Data : ModuleData * Line1 : ModuleList * Line2 : ModuleList
                                | OneByOne of Data : ModuleData * Line1 : ModuleList * Line2 : ModuleList
                                | Vertical of Data : ModuleData * Line1 : ModuleList * Line2 :…

                                28 votes
                                Vote
                                Sign in
                                Check!
                                (thinking…)
                                Reset
                                or sign in with
                                • facebook
                                • google
                                  Password icon
                                  I agree to the terms of service
                                  Signed in as (Sign out)
                                  You have left! (?) (thinking…)
                                  1 comment  ·  Admin →
                                • Support for TypeProvider nested types with static parameters

                                  Please support TypeProviders providing nested types with static parameters. This would be valuable for metaprogramming similar to how static parameterized method support is valuable compared to the language without them. It would allow a fluent-like construction of types and partially make up for the non-variable length static parameters on a single type. See https://github.com/fsharp/FSharpLangDesign/issues/88

                                  5 votes
                                  Vote
                                  Sign in
                                  Check!
                                  (thinking…)
                                  Reset
                                  or sign in with
                                  • facebook
                                  • google
                                    Password icon
                                    I agree to the terms of service
                                    Signed in as (Sign out)
                                    You have left! (?) (thinking…)
                                  • Add many more string manipulation functions to the Core.String module

                                    The Core.String module does not provide nearly enough features at present, too often we have to revert to using the the standard .NET string class which both hinders tidy piping and stops us taking advantage of curried args / partial application.

                                    I suggest that at least the following functions be added to the string module:

                                    empty : string
                                    isEmpty : string -> bool
                                    isWhitespace : string -> bool
                                    replace : string -> string -> string -> string
                                    startsWith/endsWith : string -> bool
                                    split : seq<char> -> string -> seq<string>
                                    toUpper/toLower(Invariant) : string -> string
                                    trim : string -> string
                                    trimStart/trimEnd…

                                    49 votes
                                    Vote
                                    Sign in
                                    Check!
                                    (thinking…)
                                    Reset
                                    or sign in with
                                    • facebook
                                    • google
                                      Password icon
                                      I agree to the terms of service
                                      Signed in as (Sign out)
                                      You have left! (?) (thinking…)
                                    • Make module function callable as class extension method

                                      Sometimes it's more convenient and succint to call a function using dot-notation (i.e., class method) than calling module functions with pipeline, yet module function is easier to be composed. I propose the compiler automatically generate class extension methods from module functions, based on a new attribute "CallByInstance" Example:

                                      namespace Namespace

                                      // .fsi
                                      module List =
                                      val map: ('T -> 'U) -> [<CallByInstance>] list<'T> -> list<'U>

                                      Compiler will automatically generate an extension method of list<'U>, in the *containing* namespace, i.e.,

                                      namespace Namespace

                                      module List = ...

                                      // Automatically generated:
                                      [<AutoOpen>]
                                      module ListExtension_map =
                                      type List<'U> with
                                      member this.map f list =…

                                      7 votes
                                      Vote
                                      Sign in
                                      Check!
                                      (thinking…)
                                      Reset
                                      or sign in with
                                      • facebook
                                      • google
                                        Password icon
                                        I agree to the terms of service
                                        Signed in as (Sign out)
                                        You have left! (?) (thinking…)
                                      • Support for named curried functions

                                        The idea here is to add support for labeled arguments in curried functions. This could allow to extend things like partial application to depend not only on arguments order, and also to introduce default argument values in curried functions (now it's possible only in F# type methods).

                                        This feature is supported already in ML languages like OCaml or FB Reason.

                                        16 votes
                                        Vote
                                        Sign in
                                        Check!
                                        (thinking…)
                                        Reset
                                        or sign in with
                                        • facebook
                                        • google
                                          Password icon
                                          I agree to the terms of service
                                          Signed in as (Sign out)
                                          You have left! (?) (thinking…)
                                        • Support type annotation based on expression's type

                                          It would be helpful to have type annotation made of the type of another expression:

                                          let a = 1
                                          let b : typeofexpr<a> = 2

                                          this type of type annotation exists in Oracle SQL database (tablename.column_name%type) and is implemented in jai language:

                                          https://www.youtube.com/watch?v=iVN3LLf4wMg

                                          I believe it is also possible to do similar thing with C++ templates.

                                          1 vote
                                          Vote
                                          Sign in
                                          Check!
                                          (thinking…)
                                          Reset
                                          or sign in with
                                          • facebook
                                          • google
                                            Password icon
                                            I agree to the terms of service
                                            Signed in as (Sign out)
                                            You have left! (?) (thinking…)
                                          ← Previous 1 3 4 5 8 9
                                          • Don't see your idea?

                                          F# Language

                                          Feedback and Knowledge Base