We\u2019re excited to announce the availability F# 6, shipping with .NET 6 RC2 and Visual Studio 2022 RC2. It’s the next step to making it easier for you to write robust, succinct and performant code. You can get F# 6 in the following ways:<\/p>\n
F# 6 is about making F# simpler and more performant. This applies to the language design, library, and tooling. A major goal of long-term language evolution is to remove corner-cases in the language that surprise users or are unnecessary hurdles on the path to adoption. We are very pleased to have worked with the F# community in this release to make the F# language simpler, more performant, and easier to learn.<\/p>\n
To learn more about F#, see The .NET Conf Focus Day on F#<\/a> including the F# Bonanza<\/a>, Guido van Rossum Learns F#<\/a> and Starting Your F# Journey<\/a>.<\/p>\n One of the most requested features for F# – and the most significant technical feature in this release \u2013 has been to make authoring asynchronous tasks simpler, more performant and more interoperable with other .NET languages like C#. Previously, creating .NET tasks required using This code can now become:<\/p>\n The built-in support for Task support has previously been available for F# 5.0 through the excellent TaskBuilder.fs and Ply libraries. These guided the design of the support in F# 6 and provided an important source of tests. The authors of these libraries have been major contributors to the design of F# 6, both directly and indirectly. Migrating code to the built-in support should be straightforward. There are however some differences: namespaces and type-inference differ slightly between the built-in support and these libraries, and some additional type annotations may be needed. These community libraries can still be used with F# 6, if explicitly referenced and the correct namespaces opened in each file.<\/p>\n Using If you\u2019re familiar with In general, you should consider using The In the coming months we will be working with the F# community to utilise this feature to make available two key optional packages:<\/p>\n Initially these will be delivered via community packages such as FSharp.Control.AsyncSeq. In future versions they may be integrated into FSharp.Core.<\/p>\n In F# 6, we begin allowing the syntax Up to and including F# 5.0, F# has used This is not a breaking change \u2013 by default no warnings are emitted on the use of In new code, we recommend the systematic use of F# includes the active patterns<\/a> feature that allows users to extend pattern matching in intuitive and powerful ways. In F# 6 we’ve augmented that feature with optional Struct representations for active patterns<\/a>. This allows you to use an attribute to constrain a partial active pattern to return a value option<\/a>:<\/p>\n The use of the attribute is required. At usage sites, code doesn’t change. The net result is that allocations are reduced.<\/p>\n F# 6 activates the feature “overloaded custom operations in computation expressions” which has been in preview since F# 5.0. This allows for simpler DSLs in F# including for validation and web programming.<\/p>\n The feature was previously described in the announcement for F# 5.0 preview<\/a> and implements F# RFC 1056<\/a>.<\/p>\n In F# 6, the right hand side of an \u201cas\u201d pattern can now itself be a pattern. This is important when a type test has given a stronger type to an input. For example, consider the code<\/p>\n In each pattern case the input object is type-tested. The right-hand-side of the \u201cas\u201d pattern is now allowed to be a further pattern which can itself match the object at the stronger type.<\/p>\n The F# community has contributed some key improvements to make the F# language more uniform in F# 6. The most important of these is removing a number of inconsistencies and limitations in F#’s use of indentation-aware syntax, see RFC FS-1108<\/a>. This resolved 10 significant issues highlighted by the F# users since F# 4.0.<\/p>\n For example, in F# 5.0 the following was allowed:<\/p>\n However the following was not (producing a warning)<\/p>\n In F# 6, both are allowed. This makes F# simpler and easier to learn. The F# community contributor Hadrian Tang<\/a> has led the way on this including remarkable and highly valuable systematic testing of the feature.<\/p>\n F# 6 allows This feature implements F# RFC FS-1102<\/a>.<\/p>\n F# 6 adds the This code prints the following output:<\/p>\n This feature implements F# RFC FS-1100<\/a>.<\/p>\n In F# 6, we’ve added a new declarative feature that allows code to optionally indicate that lambda arguments should be inlined at callsites.<\/p>\n For example, consider the following If the callsite is<\/p>\n then after inlining and other optimizations the code becomes:<\/p>\n Unlike previous versions of F#, this optimization applies regardless of the size of the lambda expression involved. This feature can also be used to implement loop unrolling and similar transformations reliably.<\/p>\n An opt-in warning ( In F# 6, the compiled form of generative list and array expressions is now up to 4x faster (see the relevant pull request<\/a>). Generative list and array expressions also have greatly improved debugging. For example:<\/p>\n This function generates lists of size 13 or 23 depending on the input and now executes more efficiently and breakpoints can be set on the individual lines<\/p>\n In F# 6 we have activated support for additional \u201cimplicit\u201d and \u201ctype-directed\u201d conversions in F#, as described in RFC FS-1093<\/a>.<\/p>\n This change achieves three things.<\/p>\n In F# 5.0 and before, upcasts were needed for the return expression when implementing a function where the expressions have different subtypes on different branches, even when a type annotation was present. Consider the following F# 5.0 code (StreamReader derives from TextReader):<\/p>\n Here the branches of the conditional compute a TextReader and StreamReader respectively, and the upcast was added to make both branches have type TextReader. In F# 6, these upcasts are now added automatically. This means the code can now be simpler:<\/p>\n You may optionally enable the warning Type-directed conversions also allow for automatically widening 32-bit integers to 64-bit integers more often. For example, the use of 64-bit integers is now ubiquitous in machine-learning libraries. Consider a typical API shape:<\/p>\n In F# 5.0, integer literals for int64 must be used:<\/p>\n or<\/p>\n In F# 6, widening happens automatically for Despite this change, F# still continues to use explicit widening of numeric types in most cases. For example, implicit widening does not apply to other numeric types such as NOTE: High-performance modern tensor implementations are available through TorchSharp<\/a> and TensorFlow.NET<\/a>.<\/p><\/blockquote>\n The addition of type-directed conversions allows .NET \u201cop_Implicit\u201d conversions to be applied automatically in F# code when calling methods. For example, in F# 5.0 it was necessary to use In F# 6, You may optionally enable the warning When used widely, or inappropriately, type-directed and implicit conversions can interact poorly with type inference and lead to code that is harder to understand. For this reason, some mitigations are in-place to help ensure this feature is not widely abused in F# code. First, both source and destination type must be strongly known, with no ambiguity or additional type inference arising. Secondly, opt-in warnings can be activated to report any use of implicit conversions, with one warning on by default:<\/p>\n If your team wants to ban all uses of implicit conversions you can also use This release sees the addition of five new operations to the core collection functions in FSharp.Core. These are:<\/p>\n These all perform copy-and-update operations on the corresponding collection type or sequence. Examples of using these functions can be seen in the documentation, e.g. for List.insertAt<\/a>.<\/p>\n As an example, consider the model, message and update logic for a simple \u201cTodo List\u201d application written in the Elmish style. Here the user interacts with the application, generating messages, and the With these new functions, the logic is clear and simple and relies only on immutable data.<\/p>\n In FSharp.Core 6.0.0.0 the Making F# faster and more interopable with task {\u2026}<\/h2>\n
async {\u2026}<\/code> to create a task and then invoking it with Async.AwaitTask<\/code>. With F# 6 you can now use task {\u2026}<\/code> directly to create the task and await it. For example, consider the following F# code to create a .NET-compatible task:<\/p>\nlet readFilesTask (path1, path2) =\r\n async {\r\n let! bytes1 = File.ReadAllBytesAsync(path1) |> Async.AwaitTask\r\n let! bytes2 = File.ReadAllBytesAsync(path2) |> Async.AwaitTask\r\n return Array.append bytes1 bytes2\r\n } |> Async.StartAsTask<\/code><\/pre>\nlet readFilesTask (path1, path2) =\r\n task {\r\n let! bytes1 = File.ReadAllBytesAsync(path1)\r\n let! bytes2 = File.ReadAllBytesAsync(path2)\r\n return Array.append bytes1 bytes2\r\n }<\/code><\/pre>\ntask {\u2026}<\/code> is available ubiquitously in F# code \u2013 no namespaces need to be opened.<\/p>\ntask {\u2026}<\/code> is very similar to async {\u2026}<\/code>, and both are supported. Using task {\u2026}<\/code> has several advantages over async {\u2026}<\/code>:<\/p>\n\n
task {\u2026}<\/code> is much better.<\/li>\ntask {\u2026}<\/code> is better.<\/li>\nasync {\u2026}<\/code>, there are some differences to be aware of:<\/p>\n\n
task {\u2026}<\/code> immediately executes the task to the first asynchronous yield.<\/li>\ntask {\u2026}<\/code> does not implicitly propagate a cancellation token.<\/li>\ntask {\u2026}<\/code> does not perform implicit cancellation checks.<\/li>\ntask {\u2026}<\/code> does not support asynchronous tailcalls. This means using return! ..<\/code> recursively may result in stack overflows if there are no intervening asynchronous yields.<\/li>\n<\/ul>\ntask {\u2026}<\/code> over async {\u2026}<\/code> in new code if interoperating with .NET libraries that uses tasks. Review code before switching to task {\u2026}<\/code> to ensure you are not relying on the above characteristics of async {\u2026}<\/code>.<\/p>\ntask {\u2026}<\/code> support of F# 6 is built on a foundation called \u201cresumable code\u201d RFC FS-1087<\/a>. Resumable code is a core technical feature which can be used to build many kinds of high-performance asynchronous and yielding state machines.<\/p>\n\n
async {\u2026}<\/code> using resumable code.<\/li>\nasyncSeq {\u2026}<\/code> using resumable code.<\/li>\n<\/ol>\nMaking F# simpler to learn: indexing with expr[idx]<\/h2>\n
expr[idx]<\/code> for indexing syntax<\/a>.<\/p>\nexpr.[idx]<\/code> as indexing syntax. This syntax was based on a similar notation used in OCaml for string indexed lookup. Allowing the use of expr[idx]<\/code> is based on repeated feedback from those learning F# or seeing F# for the first time that the use of dot-notation indexing comes across as an unnecessary divergence from standard industry practice. There is no need for F# to diverge here.<\/p>\nexpr.[idx]<\/code>. However, some informational messages are emitted related to this change suggesting code clarifications, and some further informational messages can be optionally activated. For example, an optional informational warning (\/warnon:3566<\/code>) can be activated to start reporting uses of the expr.[idx]<\/code> notation. See Indexer Notation<\/a> for details.<\/p>\nexpr[idx]<\/code> as the indexing syntax.<\/p>\nMaking F# faster: Struct representations for partial active patterns<\/h2>\n
[<return: Struct>]\r\nlet (|Int|_|) str =\r\n match System.Int32.TryParse(str) with\r\n | true, int -> ValueSome(int)\r\n | _ -> ValueNone<\/code><\/pre>\nMaking F# more uniform: overloaded custom operations in computation expressions<\/h2>\n
Making F# more uniform: \u201cas\u201d patterns<\/h2>\n
type Pair = Pair of int * int\r\n\r\nlet analyzeObject (input: obj) =\r\n match input with\r\n | :? (int * int) as (x, y) -> printfn $\"A tuple: {x}, {y}\"\r\n | :? Pair as Pair (x, y) -> printfn $\"A DU: {x}, {y}\"\r\n | _ -> printfn \"Nope\"\r\n\r\nlet input = box (1, 2)<\/code><\/pre>\nMaking F# more uniform: Indentation syntax revisions<\/h2>\n
let c = (\r\n printfn \"aaaa\"\r\n printfn \"bbbb\"\r\n)<\/code><\/pre>\nlet c = [\r\n 1\r\n 2\r\n]<\/code><\/pre>\nMaking F# more uniform: Discards on use bindings<\/h2>\n
_<\/code> to be used in a use<\/code> binding, for example:<\/p>\nlet doSomething () =\r\n use _ = System.IO.File.OpenText(\"input.txt\")\r\n printfn \"reading the file\"<\/code><\/pre>\nMaking F# more uniform: Formatting for binary numbers<\/h2>\n
%B<\/code> pattern to the available format specifiers for binary number formats. Consider the following F# code:<\/p>\nprintf \"%o\" 123\r\nprintf \"%B\" 123<\/code><\/pre>\n173\r\n1111011<\/code><\/pre>\nMaking F# faster: InlineIfLambda<\/h2>\n
iterate<\/code> function to traverse an array:<\/p>\nlet inline iterateTwice ([<InlineIfLambda>] action) (array: 'T[]) = \r\n for j = 0 to array.Length-1 do \r\n action array[j]\r\n for j = 0 to array.Length-1 do \r\n action array[j]<\/code><\/pre>\nlet arr = [| 1.. 100 |]\r\nlet mutable sum = 0\r\narr |> iterateTwice (fun x -> \r\n sum <- sum + x) <\/code><\/pre>\nlet arr = [| 1.. 100 |]\r\nlet mutable sum = 0\r\nfor j = 0 to array.Length-1 do \r\n sum <- array[i] + x\r\nfor j = 0 to array.Length-1 do \r\n sum <- array[i] + x<\/code><\/pre>\n\/warnon:3517<\/code>, off by default) can be turned on to indicate places in your code where InlineIfLambda<\/code> arguments are not bound to lambda expressions at callsites. In normal situations, this warning should not be enabled, however in certain kinds of high-performance programming it can be useful to ensure all code is inlined and flattened.<\/p>\nMaking F# faster: Improved performance and debugging for list and array expressions<\/h2>\n
let generateList (i: int) =\r\n [ \"a\"\r\n \"b\"\r\n for j in 1 .. 10 do\r\n \"c\"\r\n if i % 3 = 0 then \r\n \"d\"\r\n \"e\"\r\n ]<\/code><\/pre>\nMaking F# simpler and more interoperable: Implicit conversions<\/h2>\n
\n
Additional implicit upcast conversions<\/h3>\n
open System\r\nopen System.IO\r\n\r\nlet findInputSource() : TextReader = \r\n if DateTime.Now.DayOfWeek = DayOfWeek.Monday then \r\n \/\/ On Monday a TextReader\r\n Console.In\r\n else\r\n \/\/ On other days a StreamReader\r\n File.OpenText(\"path.txt\") :> TextReader<\/code><\/pre>\nlet findInputSource() : TextReader = \r\n if DateTime.Now.DayOfWeek = DayOfWeek.Monday then \r\n \/\/ On Monday a TextReader\r\n Console.In\r\n else\r\n \/\/ On other days a StreamReader\r\n File.OpenText(\"path.txt\")<\/code><\/pre>\n\/warnon:3388<\/code> to show a warning at every point an additional implicit upcast is used, as described below.<\/p>\nImplicit integer conversions<\/h3>\n
type Tensor(\u2026) =\r\n static member Create(sizes: seq<int64>) = Tensor(\u2026)\r\n<\/code><\/pre>\nTensor.Create([100L; 10L; 10L])<\/code><\/pre>\nTensor.Create([int64 100; int64 10; int64 10])<\/code><\/pre>\nint32<\/code> to int64<\/code>, int32<\/code> to nativeint<\/code> and int32<\/code> to double<\/code>, when both source and destination type are known during type inference, so in cases such as the above int32<\/code> literals can be used:<\/p>\nTensor.Create([100; 10; 10])<\/code><\/pre>\nint8<\/code> or int16<\/code>, nor from float32<\/code> to float64<\/code>, nor when either source or destination type is unknown. You may also optionally enable the warning \/warnon:3389<\/code>to show a warning at every point op_Implicit is used for method arguments.<\/p>\nFirst-class support for .NET-style implicit conversions<\/h3>\n
XName.op_Implicit<\/code> when working with .NET APIs for XML:<\/p>\nopen System.Xml.Linq\r\n\r\nlet purchaseOrder = XElement.Load(\"PurchaseOrder.xml\")\r\n\r\nlet partNos = purchaseOrder.Descendants(XName.op_Implicit \"Item\")<\/code><\/pre>\nop_Implicit<\/code> conversions are applied automatically for argument expressions when they are available and the types are known for the source expression and target type:<\/p>\nopen System.Xml.Linq\r\n\r\nlet purchaseOrder = XElement.Load(\"PurchaseOrder.xml\")\r\n\r\nlet partNos = purchaseOrder.Descendants(\"Item\")<\/code><\/pre>\n\/warnon:3390<\/code> to show a warning at every point op_implicit numeric widening is used, as described below.<\/p>\nOptional warnings for implicit conversions<\/h4>\n
\n
\/warnon:3388<\/code> (additional implicit upcast)<\/li>\n\/warnon:3389<\/code> (implicit numeric widening)<\/li>\n\/warnon:3390<\/code> (op_Implicit at method arguments)<\/li>\n\/warnon:3391<\/code> (op_Implicit at non-method arguments, on by default)<\/li>\n<\/ul>\n\/warnaserror:3388<\/code>, \/warnaserror:3389<\/code>, \/warnaserror:3390<\/code>, \/warnaserror:3391<\/code>.<\/p>\nMaking F# simpler: Updating immutable collections<\/h2>\n
\n
update<\/code> function processes these messages, producing a new model:<\/p>\ntype Model =\r\n { ToDo: string list }\r\n\r\ntype Message =\r\n | InsertToDo of index: int * what: string\r\n | RemoveToDo of index: int\r\n | LoadedToDos of index: int * what: string list\r\n\r\nlet update (model: Model) (message: Message) =\r\n match message with\r\n | InsertToDo (index, what) -> \r\n { model with ToDo = model.ToDo |> List.insertAt index what }\r\n | RemoveToDo index -> \r\n { model with ToDo = model.ToDo |> List.removeAt index }\r\n | LoadedToDos (index, what) -> \r\n { model with ToDo = model.ToDo |> List.insertManyAt index what }<\/code><\/pre>\nMaking F# simpler: Map has Keys and Values<\/h2>\n
Map<\/code> type new supports Keys<\/a> and Values<\/a> properties. These do not copy the underlying collection.<\/p>\nMaking F# simpler: Additional intrinsics for NativePtr<\/h2>\n