F# Language

This User Voice was for suggestions about the future evolution of the F# Language and Core Library.

  1. Allow static optimization conditionals

    If we write the code as below, we will get a compile error: Static optimization conditionals are only for use within the F# library

    let inline toBytes (x : ^a) : byte[] =
    (^a : (static member ToBytes : ^a -> byte[])(x))
    when ^a : byte = [|retype x : byte|]
    when ^a : string = System.Text.Encoding.UTF8.GetBytes(retype x : string)

    But allow "static optimization conditionals" is very useful, which allow us avoid to use those tricks like "Simple typeclass implementation". http://www.fssnip.net/9B

    3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  2. Implement Syntactic Macros

    At least give it a try in a private branch, and upon success, enable them publicly with a compiler switch initially.

    453 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    40 comments  ·  Flag idea as inappropriate…  ·  Admin →
  3. Remove fun keyword from lambda expressions

    Maybe make it optional?
    Otherwise it is more verbose than C#.

    270 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    17 comments  ·  Flag idea as inappropriate…  ·  Admin →
  4. Add StructOption<T>

    Currently, whenever a new Option is created, a heap allocation is required. This comes at a performance penalty.

    I suggest that a new type StructOption<T> be made available for performance.

    59 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    8 comments  ·  Flag idea as inappropriate…  ·  Admin →
  5. 7 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Flag idea as inappropriate…  ·  Admin →
  6. 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…

    121 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  Flag idea as inappropriate…  ·  Admin →
  7. Add ofObj to Seq and Array

    The Option module defines Option.ofObj which converts a potential nullable value to an option.

    Collections (Seq and array) can be null in interop scenarios, but it'd often be natural to interpret a null collection as an empty collection.

    It's possible to compose such behaviour from existing building blocks, e.g. with Option.ofObj >> Option.toArray >> Array.concat

    This seems like quite a roundabout way to do things, so I'd like to propose equivalent functions for Seq and Array:

    // seq<'a> -> seq<'a>
    Seq.ofObj

    // 'a [] -> 'a []
    Array.ofObj

    6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  8. 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…

    53 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  Flag idea as inappropriate…  ·  Admin →
  9. Better PR efforts: Write a client library to run F# code on the D-Wave quantum computers

    Quantum computing attracts a lot of attention from scientists and software developers.

    I suggest writing a client library to run F# code on the D-Wave quantum computers in order to improve F# visibility and popularity among software developers and scientists specializing in optimization, machine learning, pattern recognition and anomaly detection, financial analysis, software/hardware verification and validation, scheduling and logistics, bioinformatics.

    The world's first commercial quantum computer (D-Wave One) was built in 2010 by the D-Wave Systems Inc. (offices in Palo Alto, CA, Washington, DC, and Burnaby, British Columbia, Canada). In 2013 the D-Wave Systems Inc. shipped a 512-qubit D-Wave Two…

    2 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  10. 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…

    27 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Flag idea as inappropriate…  ·  Admin →
  11. Expand on cardinality functions Seq.exactlyOne, with Seq.tryExactlyOne and add oneOrMore, zeroOrMore

    While it is quite trivial to write these functions, I think they have merit. First of, it is good there's a Seq.exactlyOne, but it throws and if you want a non-throwing version, you'll have to write one your own. It's odd there's a creator function, Seq.singleton, but not a test-function.

    Since we have Seq.exactlyOne, it should have its logical cardinality counterparts for zero-or-one and one-or-more to be available too.

    I suggest we add:
    Seq.tryExactlyOne
    Seq.oneOrMore (throws)
    Seq.zeroOrMore (throws)
    Seq.tryOneOrMore
    Seq.tryZeroOrMore

    The reason it is better to have these in FSharp.Core is that, if one implements these by hand, it requires…

    7 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  12. 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…

    21 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  13. Allow Object Expressions from abstract base classes without members

    http://stackoverflow.com/questions/8154730/object-expression-for-abstract-class-without-abstract-members

    Object Expressions are a great feature to create instances of single-use interface / abstract class instances without polluting the namespace.

    At the moment it is impossible to inherit from an abstract class which does not define any members.

    If I have an abstract base class

    [<AbstractClass>]
    type Foo(i:int) = class end

    then I would like to be able to exten it like this:

    let foo = { new Foo(1) }

    But this errors out with

    Invalid object expression. Objects without overrides or interfaces should use the expression form 'new Type(args)' without braces.

    The suggestion obviously doesn't work, since the…

    4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  14. 2 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  15. 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…

    9 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  16. Literal sprintf

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

    16 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  17. 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
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  Flag idea as inappropriate…  ·  Admin →
  18. 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
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  19. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  20. 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.

    8 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Flag idea as inappropriate…  ·  Admin →
← Previous 1 3 4 5 9 10

F# Language

Feedback and Knowledge Base