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. An attribute enforcing usage (in F# code) of named parameters at callsite

    In some code, it's critical to have function/methods called with parameter names at call site, for readability reasons, but also for correctness.

    I would like F# to enforce this using an attribute for example: [<EnforceNamedParametersAtCallSite>]

    suppose we have this code (for sake of showing the idea):

    type Foo() =
    member x.Bar(b, a) = (a, b)

    let foo = new Foo()
    foo.Bar(1.00, 0.00)

    foo.Bar(a = 1.00, b = 0.00)

    now suppose we have this slight change in the code (just swapped the parameter names)

    type Foo() =
    member x.Bar(b, a) = (a, b)

    this would not produce the expected result

    foo.Bar(1.00,…

    4 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  2. Utilise CLR union types for discriminated unions

    CLR has native support for union types; these could provide optimization and performance opportunities for F# discriminated unions.

    6 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Flag idea as inappropriate…  ·  Admin →
  3. Add a symbol for FSI to check whether it's in 64 bit or 32 bit

    Often I want to reference different libraries based on whether the FSI is running in 32 bit or 64 bit mode. I often have to test two versions of an assembly, and it's enough of a pain just changing the flag every time, let alone change the references. Being able to do:

    #if 64_BIT
    #r "My64BitLib.dll"
    #else
    #r "My32BitLib.dll"
    #endif

    4 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Flag idea as inappropriate…  ·  Admin →

    This is approved for inclusion in a future release of F# subject to an implementation and detailed design. A pull request to implement this feature will be necessary and we encourage contributors to submit one with adequate design detail and testing to http://github.com/Microsoft/visualfsharp. Discussion of the particular version for this to be included in can be made once an implementation is available.

    Design detail can also be discussed below.

    Don Syme, F# Language and Core Library Evolution.

  4. Make F# union types like "list" that have no subtypes 'sealed'

    The compiled form of the "list" type in F# uses a single class. This is also the case for some other F# union types, e.g. ones which are enumerations where no case carries any data. For these types, the compiled representation of the union type should be marked "sealed" in F# metadata

    This is a breaking change w.r.t. hypothetical clients in other .NET languages that take advantage of this, though we know of no such instance in practice.

    1 vote
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →

    Considering this approved for F# 4.x or the first possible update after this.

    Discussion still very welcome.

    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/Library Evolution

  5. Restrict "private" for items in namespaces to mean "private to the namespace declaration group" #43

    For F# 2.x-4.0, as discussed in thie GitHub thread (https://github.com/Microsoft/visualfsharp/issues/43#issuecomment-70650925), a "private" module or type in a namespace is actually accessible from anywhere in that assembly contributing to the same namespace.

    The suggestion is to emit a warning when such an item is accessed from outside the immediate namespace declaration group in which it is declared. For example, we would give a warning if it is accessed from another file in the same namespace in the same assembly.

    4 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  6. Allow opening of static classes (matching the C# design)

    You currently can't "open" a static class e.g. System.Console - only modules or namespaces. We should be able to also open static classes as well.

    31 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Flag idea as inappropriate…  ·  Admin →
  7. Add possibility to use break and continue in f# loops. And do while loop

    It very often looks better than recursion, and it would be wonderful to have this possibility

    12 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  Flag idea as inappropriate…  ·  Admin →
  8. Implement first-class lensing / lenses in F#

    When working with complex state structures, functional programming is, without a great deal of additional tooling (tooling that does not satisfactorily exist in F#), highly inconvenient, verbose, and even error-prone. These problems are so pronounced that many cite them as a reason to label functional programming itself as inapplicable to the domains within which complex state structures are inherent!

    As functional programmers, we believe otherwise, and many even believe that it is in the domain of dealing with complex state artifacts that functional programming is especially beneficial and necessary! However, with such weak syntactic constructs such as these -

    let…

    168 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    15 comments  ·  Flag idea as inappropriate…  ·  Admin →
  9. Support .NET Core and CoreCLR

    .NET Core is the new cloud runtime model for the CLR and used in ASP.NET vNext.

    377 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Flag idea as inappropriate…  ·  Admin →

    Strictly speaking this issue is not meant for https://fslang.uservoice.com, since it is about targeting a particular platform with the tooling, rather than the F# language or core library design itself.

    However, I’m leaving it open for now since it’s getting so many votes. We may close it sometime soon to release the votes.

    In any case, this work is planned by the Microsoft visualfsharp team and other contributors. Please contribute to the work at the http://github.com/Microsoft/visualfsharp repository and follow that repository for more details and updates.

    Relevant issues: https://github.com/Microsoft/visualfsharp/issues/387 and https://github.com/Microsoft/visualfsharp/pull/499

    Don Syme, F# Language and Core Library Evolution

  10. Support bind (e.g. "await") in the middle of expressions, possibly using !! operator

    that does the binding implicitly; so that it wouldn't be necessary to bind every monadic expression to a name. In the case of async workflows, it would behave like the C# await keyword.
    With this operator, instead of this:
    let task= tasync{
    let! response = http.GetAsync(uri)
    let! string = response.Content.ReadAsStringAsync()
    let! res = processAsync(string)
    return res
    }
    it would be possible to write code like this:
    let task= tasync{ return !! processAsync(!!(!!http.GetAsync(uri)).Content.ReadAsStringAsync()) }

    Or write this:
    let t= opt{ return ((!!x) + !!y) / !!z}
    instead of this:
    let t= opt{
    let! xx = x
    let! yy = y
    let!…

    10 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Flag idea as inappropriate…  ·  Admin →
  11. Display current parameter type in tooltip for generic function

    I posted this on CodePlex (https://visualfsharp.codeplex.com/workitem/172), and Don Syme asked me to put it here as well.

    The C# editor in Visual Studio displays the actual parameter types involved in the tooltips for generic class instances and method invocations. The F# editor only does that for objects and methods, but oddly not for F# types/functions; shouldn't this information be quite readily available?

    Having this kind of information at hand would especially make it quite a bit easier to follow the transformation of data through pipe chains, even more so as this type of display is also completely absent…

    11 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Flag idea as inappropriate…  ·  Admin →
  12. Properly print 'None' for option types from FSI

    FSI output properly handles 'Some x', but often prints 'None' as 'null', apparently when the value is part of a larger type.

    let x : uint16 option = None
    correctly results in: val x : uint16 option = None

    let y : string * uint16 option = "", None
    instead prints: val y : string * uint16 option = ("", null)

    18 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Flag idea as inappropriate…  ·  Admin →
  13. Add a Option.getOrDefault and other new functions to the Option module

    Like List.nth, defaultArgs has the parameters in the "wrong order" to be able to be used in partial application. List.item is solving that problem, we should also do the same for defaultArg

    15 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  Flag idea as inappropriate…  ·  Admin →
  14. An CLIVirtual attribute

    Just as you can use CLIMutable to store records using Entity Framework wouldn't is be nice to be able to set an CLIVirtual attribute on a record field of an ICollection type so that Entity Framework can do lazy loading. See also http://stackoverflow.com/questions/26775760/how-to-create-a-virtual-record-field-for-entity-framework-lazy-loading

    22 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Flag idea as inappropriate…  ·  Admin →
  15. Allow negative indices in indexing and slicing like python

    Example: permit usage of a.[..-2] instead of a.[..a.Length-1]
    The compiler could just do that conversion behind the scenes, so it would work with existing types that have custom indexing and slicing

    39 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Flag idea as inappropriate…  ·  Admin →
  16. Add support for Haskell-style type annotations

    Although it's typically preferred to let the compiler handle types, it is often necessary to provide type annotation. Sometimes this is to help the compiler understand the types a function can take, often it is done to help other developers understand your code, and in my personal use, I frequently add type annotations to ensure the compiler will catch typos I make which change a function's return type.

    Although not as verbose as other .NET languages, the F# type annotations do add verbosity to a function definition, look cluttered compared to Haskell's syntax (personal opinion), and do not match the…

    58 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    10 comments  ·  Flag idea as inappropriate…  ·  Admin →
  17. 42 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    9 comments  ·  Flag idea as inappropriate…  ·  Admin →
  18. Allow TypeProviders to supply location with errors

    When a custom type provider fails, the type provider will typically throw, there is not much else to do.

    I suggest to add the ability to add an error location when something fails. This would allow to pinpoint with squigglies where the error is in ie json/sql/whatever.

    Perhaps the simplest non-breaking implementation would be to add a known exception type that contains a file location and a range. So the TP still just throws, but adds this information where possible.

    6 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Flag idea as inappropriate…  ·  Admin →

    Approved in principle for F# 4.0 (or later, depending), along with “allow type providers to report warnings”. subject to a suitable implementation being submitted. Both are entirely reasonable

    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/Library evolution

  19. Wildcard self identifiers

    Two underscores are frequently used in member definitions to denote an ignored "self" identifier. This seems like a hack given that the language already provides a wildcard pattern that represents an unused value.

    9 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  Flag idea as inappropriate…  ·  Admin →

    I’m marking this as approved in principle for F# 4.×. you are invited to submit a quality and tested implementation would be needed, to be submitted to http://github.com/Microsoft/visualfsharp.

    See http://fsharp.github.io/2014/06/18/fsharp-contributions.html for details about contributing to the F# language and core library

    FWIW I’ve actually taken a look at this once or twice and it was surprisingly invasive to implement. But by all means give it a go and ask if you need help.

    Don Syme
    BDFL F# Language/Core Library Evolution

  20. Fix ReflectedDefinition for top-level pattern-matched let bindings

    Right now, when you do something like this:

    [<ReflectedDefinition>]
    let (a, b) = (1, 2)

    The compiled result is roughly equivalent to:

    let private generatedIdent = (1, 2)
    [<ReflectedDefinition>] let a = fst generatedIdent
    [<ReflectedDefinition>] let b = snd generatedIdent

    As you can see, the actual expression (1, 2) doesn't get reflected. This makes such definitions unusable for most use cases of ReflectedDefinition. As far as I can tell, this could be fixed by simply adding a ReflectedDefinition of generatedIdent.

    9 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →

    I’ve marked this as approved for F# 4.x+.

    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 http://github.com/Microsoft/visualfsharp. See http://fsharp.github.io/2014/06/18/fsharp-contributions.html for details on contributing to the F# language and core library.

    Don Syme, F# Language and Core Library Evolution

F# Language

Feedback and Knowledge Base