F# Language

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

  1. Add 'serializable' and 'blittable' constraints for types

    I think it would be a good idea to let the F# compiler reason about serializable types. This could be implemented along the lines of the 'comparison' constraint, i.e. based upon an assortment of criteria for deciding when it is satisfied.

    For instance, a type could be statically deemed serializable iff
    * it is primitive, string, byte array, etc.
    * It is a subtype of System.Exception
    * it is a managed class or struct that carries the Serializable attribute.

    3 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 →
  2. Allow defining extern methods in a class

    Currently it appears that extern methods for platform invoke only work properly when used inside of a module (see this discussion: http://stackoverflow.com/questions/22275072/why-does-the-f-compiler-give-an-error-for-one-case-but-not-the-other) this limitation poses problems when organizing your code in an efficient manner and results in having multiple modules defined (for an example, see here: http://stackoverflow.com/questions/25004314/working-with-safehandles-in-f)

    It would be nice if extern methods could be defined in classes (and work correctly) even if the scope of the method is always limited to the type itself.

    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 →

    This is now “approved in principle” for some version of F# 4.x or beyond. It is entirely reasonable to eventually allow this for F#.

    However, because there is a workaround (using a module), and because the implementation and testing is a little complicated, involving new code paths, it may be that the feature is not seen as high priority. Only a fully implemented and tested feature would be accepted.

    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, Current BDFL for F# Language Evolution

  3. Syntactically describe dependencies between files (by using '#requires', '#load' or extending 'open' syntax)

    With F# becoming more and more multi-editor and cross-platform, it is becoming increasingly difficult to teach all build/edit tools about F#'s file order. The F# community are currently struggling to "update" each new build/edit tool to understand that F# actually needs a file order.

    Part of the problem is that there is no standard textual way to specify this file order except as command line arguments, and these are not stored in an editable form. There is no standard way to specify the F# file order. We need an (optional) solution to this problem that is closer to home and…

    7 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  3 comments  ·  Flag idea as inappropriate…  ·  Admin →
  4. Allow "inline" keyword in the case "let f = fun a -> ..."

    Currently, the code "let inline f = fun a -> ..." does not compile, but the code "let inline f a = ..." does compile. Since the two mean the same thing, "inline" should be allowed on both.

    3 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 →

    This is approved for inclusion in a future release of F# subject to completion of an RFC and implementation.

    An RFC can be submitted to https://github.com/fsharp/FSharpLangDesign/tree/master/RFCs

    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.

  5. 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 →
  6. Provide better support for structural typing

    In F#3 you can declare a function which can operate on e.g. records which has no relation aside from the fact that they share e.g. field name + type. This can occasionally be useful - however, the syntax for achieving this is somewhat awkward e.g. http://codebetter.com/matthewpodwysocki/2009/06/11/f-duck-typing-and-structural-typing/

    If there were a more succinct way to achieve this, it could be a very powerful feature e.g.

    decorating a function with [<StructuralTyping>] to automatically indicate to the compiler to infer the implicit structure of the type, or at least simplifying the syntax to not have to mess around with "'a member" etc..

    17 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 →
  7. Allow nested property setters and collection property setters in initializers

    I suggest we consider allowing A.B=expr property setters in initializers, e.g.

    UIButton(UIButtonType.Custom, Layer.BorderWidth = 1.0, Layer.BorderColor=UIColor.Gray.CGColor, Radius = size / 2.0)

    cf. https://github.com/dvdsgl/shallow/blob/master/Shallow/RoundButton.fs#L6

    Also, we should consider allowing collection setters, e.g.

    C(CollectionProperty = [ 1;2;3 ])

    where CollectionProperty has the "Add" pattern of C#. One design would make it tht any IEnumerable<T> would be assignable, where T corresponds to the type of an Add method, though that may not be fully compatible with the C# mechanism.

    12 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 →
  8. Allow Object expressions to have attributes applied to them

    In the simplest case something like this would be possible:

    [<MyAttribute>]
    let makeResource name =
    { new System.IDisposable
    with member this.Dispose() = printfn "%s disposed" name }

    And then when the code is compiled the expression thats generated would also have the attribute applied to it.

    This would interoperability with frameworks that use declarative attributes which would otherwise require adding a full type

    4 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 →
  9. 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 →
  10. 45 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 →
  11. Support for Generic Provided Type Definitions

    This is needed for TPs that interop with other languages. A good example is the TypeScript type provider in Funscript

    85 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. Internationalized printf formatting of numbers

    Most non-english speaking countries use "," as deciamal separator.
    it would be nice if I could write <sprintf "%,1f" 2.222> instead of <sprintf "%.1f" 2.222> to get a comma as a decimal separator.

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

    This is a reasonable suggestion. From the point of view of the F# language design, I would be happy to see a well-considered set of extensions to printf added to F# 4.x or later versions.

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

    We would strongly welcome an implementation proposal and initial testing for this.

    Implementations of approved language design 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..

    Thanks
    Don Syme, F# Language and Core Library Evolution

  13. Add string interpolation to println syntax (from Swift)

    The new language from Apple, Swift has a really nice syntax for println:
    http://en.wikipedia.org/wiki/Swift_(programming_language)

    let people = ["Anna": 67, "Beto": 8, "Jack": 33, "Sam": 25]
    for (name, age) in people {
    println("\(name) is \(age) years old.")
    }

    We could steal the idea but use % instead of \ for a better fit. It would also be compatible, and combinable (is that a word?) with existing printfn syntax:

    let name = "Robert"
    printfn "Hi %(name), your age is %d"
    printfn : int -> string

    Naturally there would be compiler errors if name does not exist.

    179 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    19 comments  ·  Flag idea as inappropriate…  ·  Admin →
  14. Allow specifying subset of type arguments explicitly

    Say we have a generic type Frame<TRow, TColumn>. When using instance methods of the frame, it is possible to write a generic method that takes a single additional type parameter - for example, to get a column as a specific type:

    frame.GetColumn<float>("Value")

    However, doing the same thing using module and function is not possible, because the corresponding `getCol` function requires three type arguments (TRow, TCol and the additional one):

    frame |> Frame.getCol<_, _, float> "Value"

    It would be nice if F# had some mechanism that would allow specifying only subset of the type parameters. For example:

    let getCol<[<RequiresExplicitTypeArguments>] 'T, 'TCol,…

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

    Updating to planned to indicate this is approved in general terms. A detailed design and implementation would be needed.

    Implementations of approved language design 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

  15. Allow "params" dictionaries as method arguments

    When interoperating with languages that are more dynamic than F# (like Python, Matlab or R), we can often get the list of available methods/functions, but we cannot always get the names and types of parameters. For example, in R provider, you sometimes have to write:

    namedParams [ ("xval", days), ("yval", prices), ("another", box 1) ]
    |> R.plot

    It would be nice if I could put the "Params" attribute on a "IDictionary<string, 'T>" and let the compiler provide all additional named parameters as a dictionary:

    R.plot(xval=days, yval=prices, another=1)

    This would have other uses - for example, when creating a Deedle data…

    30 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 →

    Updating to planned to indicate this is approved in general terms. A detailed design and implementation would be needed.

    Implementations of approved language design 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

  16. Allow implementation of generic methods with constraints of the form 'T :> 'U

    Currently this is solved as 'a = 'b.
    This limitation does not exists in C# and it makes impossible to interact with some existing libraries, as in this case http://stackoverflow.com/questions/23643989/is-it-possible-to-implement-the-idbsett-interface-in-f
    This will also allow to work around F#'s lack of generic (co/contra)-variance.

    136 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    7 comments  ·  Flag idea as inappropriate…  ·  Admin →
  17. Add NameOf operator to follow C#/VB update

    The Roslyn compiler currently (as of 2014-05-08) has a new NameOf operator listed as "Planned" for both C# and VB:
    (https://roslyn.codeplex.com/wikipage?title=Language%20Feature%20Status&referringTitle=Documentation)

    Pending its arrival there, it would be awesome to get something similar in F# as well.

    127 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    7 comments  ·  Flag idea as inappropriate…  ·  Admin →
  18. Stronger type directed conversion from functions to .Net delegates

    It seems in some cases type directed conversion from functions to .Net Func<_,_> delegates only works if the called method has overloads. It would be convenient if it worked the same way for methods without overloads as well.

    For example:

    open System.Linq
    let even n = n % 2 = 0
    let seqA = seq { 0..2..10 }

    seqA.Where(even) // works
    seqA.All(even) // does not work

    http://stackoverflow.com/questions/23256355/passing-f-function-to-ienumerable-where-vs-ienumerable-all

    http://stackoverflow.com/questions/12933366/f-func-type-inference-difference-between-seq-and-pseq-todictionary

    25 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  3 comments  ·  Flag idea as inappropriate…  ·  Admin →
  19. Support for type classes or implicits

    (Updated the suggestion to "type classes or implicits", and edited it)

    Please add support for type classes or implicits.

    Currently, it's possible to hack type classes into F# using statically resolved type parameters and operators, but it is really ugly and not easily extensible.

    I'd like to see something similar to an interface declaration:

    class Mappable =
    abstract map : ('a -> 'b) -> 'm<'a> -> 'm<'b>

    Existing types could then be made instances of a type classes by writing them as type extensions:

    type Seq with
    class Mappable with
    member map = Seq.map

    type Option with
    class Mappable with …

    392 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    18 comments  ·  Flag idea as inappropriate…  ·  Admin →
  20. Support markdown in documentation comments

    F# currently supports documentation comments with either XML tags or no tags. The no tags format is convenient to write, but does not allow formatting the comments for the VS IDE. Use of XML tags allows formatting the documentation comment, but the act of writing the documentation comment becomes a heavy burden as XML is not a very convenient format for manual editing. I would like to suggest supporting some lighter-weight formatting syntax such as markdown.

    19 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 →

F# Language

Feedback and Knowledge Base