F# Language

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

  1. Close User Voice in favor of GitHub issues.

    I really believe we should close UserVoice in favor of using GitHub issues (maybe separate repository for it? ). Here are few reasons for it:
    * Bad UX
    * Need to monitor and maintain separate communication channel
    * No comment editing
    * No markup for code samples
    * No markdown
    * Can't embed images
    * No mentions and notifications
    * Only 10 votes which reduce people ability to vote (especially in so old project as F# - many people already used all their votes over the years)
    * No more fake accounts to workaround votes limit
    * God damn this…

    299 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    12 comments  ·  Flag idea as inappropriate…  ·  Admin →
  2. Make "ModuleSuffix" the default if a type has the same name

    [<CompilationRepresentation(CompilationRepresentationFlags.ModuleSuffix )>]

    This attribute is so commonly used on top of modules. But it is a bit verbose and tedious. I suggest offer an alternative shortcut like [<ModuleSuffix>] or achieve the same effect by a compiler switch.

    Update: the proposal has been adjusted to say that ModuleSuffix is implied if a type and a module have the same name within the same namespace declaration group

    13 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 →
  3. Support FSharpType and FSharpValue methods on all profiles

    The following functions are missing from FSharp.Core reflection support for Profile78, 259 and .NET Core. This is because the “BindingFlags” type is not available in those profiles.

    type FSharpValue =
    static member MakeRecord: recordType:Type * values:obj [] * ?bindingFlags:BindingFlags -> obj
    static member GetRecordFields: record:obj * ?bindingFlags:BindingFlags -> obj[]
    static member PreComputeRecordReader : recordType:Type * ?bindingFlags:BindingFlags -> (obj -> obj[])
    static member PreComputeRecordConstructor : recordType:Type * ?bindingFlags:BindingFlags -> (obj[] -> obj)
    static member PreComputeRecordConstructorInfo: recordType:Type * ?bindingFlags:BindingFlags -> ConstructorInfo
    static member MakeUnion: unionCase:UnionCaseInfo * args:obj [] * ?bindingFlags:BindingFlags -> obj
    static member GetUnionFields: value:obj * unionType:Type * ?bindingFlags:BindingFlags -> UnionCaseInfo…

    1 vote
    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 →
  4. Add support for symbolic stacktraces in computation expressions

    One of the biggest problem in async or computation expressions in general is lack of proper stacktraces when exceptions are raised. This is a major annoyance when debugging in the large, often leading to errors whose origin cannot be traced.

    I recently made a blog post arguing for the addition of language features that would make symbolic stacktraces possible for computation expression authors: https://eiriktsarpalis.wordpress.com/2015/12/27/reconciling-stacktraces-with-computation-expressions/

    Symbolic stacktraces is a feature that has already appeared in languages like C# (https://github.com/ljw1004/async-exception-stacktrace) and JavaScript (http://www.html5rocks.com/en/tutorials/developertools/async-call-stack/)

    59 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 →
  5. Allow types and modules to be mutually referential (not across files, only within a closed scope in a single file)

    Currently types and modules can't be mutually referential - a group of types can be using "type X = ... and Y = ... "

    I propose we allow a collection of types and modules within a single file to be mutually referential, either by using

    type X = ... and module Y = ...

    or by allowing a #mutrec declaration within a module or namespace declaration group that "turns on" mutual-reference within that scope (no larger than the file). The latter option is appealing as "and module" is not required (no new syntax is required) and the syntax of…

    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 →
  6. interpret `do! action` as `let! () = action in zero` when the Builder has no Return defined

    In general there are two types of workflows represented by computation expressions:
    1) process (async)
    2) sequential (seq)

    The former usually uses return or return!, the later yield and yield!.

    With asyncSeq it's actually a combination of both worlds, but the main purpose is to be sequential, and also allow side effects to happen (do! Async.Sleep 200).

    Currently `do! action` is interpreted as `let! () = action in return ()`, with this the Builder has to provide the Return method. With it in place also return keyword becomes available.
    In case of asyncSeq the result of `return expr` is completely…

    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 →
  7. Importing DLL's from projects in current solution into F# interactive

    It is currently a hassle to import references to DLL's from projects in the current solution because full paths has to be given and recursive dependencies have to be handled manually. Why not make it possible to import a "project" by name along with all dependencies into F# interactive.

    9 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 →
  8. add Async.Choice to FSharp.Core

    Async.Choice is super useful (e.g. very important in Paket) but hard to implement. There are couple of implementations floating around like http://www.fssnip.net/dO but it's ahrd to decide which one is correct. We should add it to the core.

    12 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. Make F# quotations and FSharp.Reflection usable with mscorlib and FSharp.Core for other target profiles

    F# quotations have nodes related to tuple, delegate, function, union and record types. Likewise, FSharp.Reflection has helpers related to union and record types.

    When running on .NET 4.x everything works fine. But if you use ReflectionOnlyLoadFrom to get an FSharp.Core for an alternative profile, then you can't use most F# quotation nodes correctly - all sorts of things go wrong when you try to construct nodes that refer to the types stemming from this "other profile" FSharp.Core. Note you are still running .NET 4.x code, but reflecting over assemblies relevant to other profiles.

    This also applies when implementing the System.Reflection…

    6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    completed  ·  2 comments  ·  Flag idea as inappropriate…  ·  Admin →
  10. Add Result<'Success,'Failure> to FSharp.Core

    In order to be able to write code that you can easily consume that does not throw an exception have a fsharp core type with the following signature:

    type Result<'TSuccess,'TError> =
    | Success of 'TSuccess
    | Error of 'TError

    from
    https://github.com/fsharp/fsharp/issues/479

    17 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 →
  11. F# compiler should support CallerLineNumber, CallerFilePath etc

    .Net has attributes like CallerLineNumber, CallerFilePath (see MSDN https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.callerlinenumberattribute(v=vs.110).aspx). These are supported by C# compiler but not F# compiler. This seems to be an important feature to have. Especially when writing service components, the logging facility normally requires a compile-time approach to populate the file path and line number. In C/C++, this can be achieved by implementing the logging API using Macros. In C#, it can be done with CallerLineNumber, CallerFilePath attributes. There seems no viable approach in F#. Moreover, if there's an existing C# logging library that used CallerLineNumber attribute, such library cannot be taken advantage easily from…

    15 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 →
  12. Allow to use struct constructors as functions

    Similar to the suggestion [Allow to use class constructors as functions](http://fslang.uservoice.com/forums/245727-f-language/suggestions/5663317-allow-to-use-class-constructors-as-functions), it would be nice if we use constructors of structs as functions.

    1 vote
    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 →
  13. Allow all inferrable SRTP constraints to be written in signatures

    See https://github.com/Microsoft/visualfsharp/issues/392. Basically F# will in some situations infer statically-resolved-constraints like

    (A or ^b) : (static member X : ...)

    where A is a concrete class name. However these constraints can't be written in signatures. It is reasonable to lift this restriction

    14 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 →
  14. Please make correct type casting for bigint in F#

    I have been using the forward pipe to convert values and came up against the problem where the following code would work

    let IntToFloat = 10 |> float
    let FloatToInt = 10.0 |> int

    But the equivalent bigint code would not work:
    let FloatToBigint = 10.0 |> bigint

    The reason why FloatToBignint does not compile is because the F# compiler is looking for a function called bigint that has an input of type float!

    So, as soon as I had the following function declared:
    let bigint(x:float) = bigint(x)

    the code:
    let FloatToBigint = 10.0 |> bigint
    works perfectly.

    Please make…

    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 →
  15. Support Multiple Properties in StructuredFormatDisplayAttribute

    There's currently a limitation in StructuredFormatDisplayAttribute whereby you can only provide a single property in the Value.

    So for a type like this: type Person = {First: string; Last: string} I have to create another property like FullName to use in StructuredFormatDisplayAttribute. The fix/enhancement should be easy to do, and something I could probably just do myself.

    I first broached this subject on StackOverflow and Tomas Petricek suggested I create an issue for this. Here's the link to the SO question: http://stackoverflow.com/questions/28505368/can-i-use-multiple-properties-in-a-structuredformatdisplayattribute

    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 →
  16. Release the F# Visual Studio plugin code

    It would be very interesting to have access to the VS plugin code for F#, particularly the debugger integration.

    It would allow tools vendors (IntelliFactory, Xamarin...) to re-use and even tweak the debugger. Community contributors could work towards improving the F# debugging experience, for example by adding support for autos and "Edit and Continue".

    5 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 →
  17. Add more persistent collections

    Immutability is one of the large advantages of functional programming. However, in order to effectively utilize such immutability, a good set of persistent data structures are necessary.

    Other modern functional programming languages like Scala and Clojure offer a much richer set of immutable data structures, which makes F# feel lacking in this respect, and this in turn encourages developers to fall back to regular .NET collections.

    Whereas third party alternatives exist, common data structures are so general, that they should be in the std. library. We should at least add the following:

    - persistent queue
    - persistent vector

    But we…

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

    Many thanks for this suggestion. It is being marked as completed – evolution will be done through additional packages like those mentioned, and there are already several good packages available.

    For discussion see the comments below. Further discussion and links to newly available libraries welcome

    Don Syme, F# Language and Core Library Evolution.

  18. Add 'except' function to core collection modules

    In C# you can do

    xs.Except(ys)

    Without defining a function, the F# equivalent is

    xs |> Seq.filter (fun x -> ys |> Seq.exists ((=)x) |> not)

    Of course, with the F# 4.0 collection normalization you can replace "Seq.exists ((=)x)" with "Seq.contains x".

    If you convert to a Set first then there's Set.difference but the problem is that it is not in correct order for partial application so can't be used in a pipeline, and the other argument also needs to be a set.

    7 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 →
  19. Revise the reserved keyword list (e.g. remove "method")

    The keyword "method" is currently reserved for future use.

    In many web programming scenarios "method" refers to the HTTP method (GET/POST) and the fact that you currently have to escape the keyword and write ``method`` is annoying. Calling function parameter "meth" instead works (though some people may find this an unfortunate naming ;-)), but it is against F# coding guidelines. And furthermore, this only helps when you're defining the API, but sometimes you need to consume C# API that already has "method" as optional argument.

    I think that the F# community is quite happy with using the name "member" for…

    8 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 →
  20. Add Checked.int8/uint8 and Nullable.int8/uint8/single/double

    This is the tracking issue for https://github.com/Microsoft/visualfsharp/pull/19

    F# defines "int8" and "uint8" as synonyms for "sbyte" and "byte", both as types and operators. While reviewing the behaviour of "open Checked" (which brings new versions of operators into scope) we noticed that new versions of the "int8" and "uint8" operators are not defined in the "Checked" module. This is inconsistent, though a simple workaround is to use the checked "sbyte" and "byte" operators instead.

    We also noticed that "Nullable.int8" and "Nullable.uint8", "Nullable.single" and "Nullable.double" are missing.

    The proposal is to add these.

    1 vote
    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 →
← Previous 1 3

F# Language

Feedback and Knowledge Base