F# Language

This User Voice was for suggestions about the future evolution of the F# Language 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. Add support for implicit operators to facilitate language interop

    Add support for implicit operators to facilitate language interop instead of having to write an explicit operator like:
    http://stackoverflow.com/questions/10719770/is-there-anyway-to-use-c-sharp-implicit-operators-from-f

    15 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 →
  2. Copy-and-update on class types and on records of different types.

    People sometimes find it hard to transition from records to class types - something which comes up when seeking to encapsulate some of the details of the record type.

    One particular reason for this is because their codebase may uses copy-and-update on record types. One approach to easing the transition would be to support copy-and-update on class types, as long as the class type follows a particular design pattern.

    One pattern-based approach could permit both normal record syntax and copy-and-update syntax, e.g.

    [<RecordSyntax>]
    type R(a:int, b:int) =
    member x.A = a
    member x.B = b
    member x.C = f(a,b)

    with …

    25 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 →
  3. Provide covariance/contravariance language support with syntaxes in F# in sync with covariance/contravariance in C#/VB

    Covariance/contravariance has its beginning in CLR 2.0 and also with the introduction of generics in .NET 2.0 (also in F#, C# and VB)

    Then in C# 4.0 and VB 10, we have covariance/contravariance supports in the language itself. Currently we don't have support for these covariance and contravariance in F#.

    I know it is a runtime feature of CLR 2.0 and 4.0 and I don't want to play catch up with C# and VB.

    But this covariance/contravariance support in C# and VB are powerful to use and also have proven to provide cleaner and clearer ways to understand the code…

    150 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  10 comments  ·  Flag idea as inappropriate…  ·  Admin →
  4. Syntax for turning properties into functions

    When we have F# records and classes (including the ones generated by type providers), we end up having to write things like this a lot:

    (fun x -> x.Name)

    It would be nice to have some shorthand for this, similar to what we can do with static members (but nicer than the Scala syntax please)

    457 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  37 comments  ·  Flag idea as inappropriate…  ·  Admin →
  5. 98 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Flag idea as inappropriate…  ·  Admin →
  6. Improve optional parameter interop between F# and C#

    It would be nice if the F# compiler automatically inserted [<Optional;DefaultParameterValue(null)>] in all optional parameters of methods declared in F# classes, so they would be easier to use from C#

    It would also be nice if the constructors of records also used this for parameters of type Option<_>

    20 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 →
  7. 11 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Flag idea as inappropriate…  ·  Admin →

    This is approved-in-principle for F# 4.x+

    A detailed design is needed. I would prefer one that is idiom-based and doesn’t force type providers to use a later FSharp.Core.dll

    Implementations of approved language design items can now be submitted as pull requests to the appropriate branch of http://github.com/Microsoft/visualfsharp. See http://fsharp.github.io/2014/06/18/fsharp-contributions.html for information on contributing to the F# language and core library.

    Don Syme, F# Language and Core Library Evolution

  8. 111 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 →

    Marking as “approved in principle” (it will show as “planned”).

    However, in reality it is both relatively low priority and relatively hard to implement, so I don’t expect this to happen any time soon.

    For example, we would have to reverse-map the metadata associated with F#-specific types. This is already done in F# reflection FSharpType.IsRecord and so on.

  9. Optional and named parameters on let bindings on modules

    Optional and named parameters are supported in static methods, but not in let bindings on modules. This many times forces you to use a static class instead of a module, which has some inconvenients. Ocaml has this, so I'm guessing is doable.

    131 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  11 comments  ·  Flag idea as inappropriate…  ·  Admin →
  10. Allow to define types at expression scopes

    The suggestion is to allow "type X = ..." in an expression, e.g.

    let f () =
    type X = A | B
    let x = (A,A)
    let y = (B,B)
    if (x=y) then true else false

    36 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    10 comments  ·  Flag idea as inappropriate…  ·  Admin →
  11. Enable a compiler-warning when a recursive algorithm is not tail-recursive

    Add an TailRecursiveAttribute to enable a compiler-warning when a recursive algorithm is not tail-recursive. This should ideally also cover recursive seq { .. } and async { ... } expressions.

    311 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    23 comments  ·  Flag idea as inappropriate…  ·  Admin →

    I am generally in favour of addressing this in F# 4.x+. I would want seq { .. } and async { … } tailcalls to also be addressed.

    A more detailed design is needed and some trialling would be great. Jack’s work is a great start. However, this is not an easy piece of work to do in a non-invasive way and my own experiments in this area have not yet led to something I feel confident to include in the F# language design.

    An implementation and testing would need to be provided by someone in the F# community (possibly including Microsoft or Microsoft Research, though not limited to them).

    Currently, initial implementations of approved language design can be submitted as pull requests to the appropriate branch of https://github.com/Microsoft/visualfsharp. See http://fsharp.github.io/2014/06/18/fsharp-contributions.html for info on how to contribute to the F# language/core library design

    I encourage you to consider continue…

1 2 6 7 8 10 Next →

F# Language

Feedback and Knowledge Base