F# 10 is now shipping with .NET 10 and Visual Studio 2026.\nThis version is a refinement release focused on clarity, consistency, and performance, bringing small but meaningful improvements that make your everyday code more legible and robust.<\/p>\n
You can get F# 10 today in a few ways:<\/p>\n
With F# 10, we’re continuing our journey to make the language simpler and more performant.\nKey ergonomic improvements include scoped warning suppression<\/a>,\nmore consistent syntax for computation expressions<\/a>,\nand better support for auto property accessors<\/a>.\nThe release also includes an infrastructure upgrade to speed up compilation and interactive tooling in the form of the new type subsumption cache<\/a>.<\/p>\n The first feature I want to introduce for F# 10 is a much-requested one: the ability to suppress warnings in arbitrary code sections.\nOur compiler now supports the Let’s take a look at a motivating example:<\/p>\n Of course, we can add a With F# 10, you can delimit the section explicitly, applying the warning suppression to as narrow a scope as a single line:<\/p>\n Conversely, if a warning is disabled globally (e.g., via a compiler flag), you can enable it locally with Compatibility:<\/strong><\/p>\n This feature is accompanied by several changes that improve the consistency of Script behavior is also affected.\nIn previous versions, a A frequent pattern in object-oriented programming is to create publicly readable but privately mutable state.\nBefore F# 10, achieving this required explicit property syntax with backing fields, which added significant boilerplate:<\/p>\n With F# 10, you can apply distinct access modifiers to individual property accessors.\nThis allows you to specify different access levels for the getter and setter of a property inline,\nenabling common patterns like publicly readable but privately mutable state without verbose boilerplate.<\/p>\n Now you can rewrite the above as:<\/p>\n Worth noting:<\/strong><\/p>\n You can place an access modifier either before the property name (applying to both accessors) or before individual accessors, but not both simultaneously.<\/p>\n Also, this feature does not extend to signature (.fsi) files.\nThe correct signature for the Optional parameters can now use a struct-based Previous versions of F# always used the heap-allocated Now you can use the Choose this struct-based option for small values or frequently constructed types where allocation pressure matters.\nUse the default reference-based Computation-expression builders (for example, coroutines or other builders implemented with resumable state machines) can now opt into tail-call optimizations.\nDuring desugaring, the compiler recognizes when an expression like If a builder implements:<\/p>\n These Examples:<\/p>\n Compatibility:<\/strong><\/p>\n This change can be breaking if a builder already defines members with these names.\nIn most cases, it is backward-compatible: existing builders continue to work without modification when compiled with F# 10.\nOlder compilers will simply ignore the new A long-standing inconsistency in type annotation syntax for computation expression bindings has been resolved.\nYou can now add type annotations on Prior versions of F# required parentheses for type annotations in computation expression bindings.\nFor example, Now you can write type annotations without parentheses, matching the style of ordinary Prior versions of F# rejected the discard pattern in The discard pattern ( Now you can use the discard pattern directly, clarifying your intent and matching the behavior of Structural validation has been tightened in this release to reject misleading module placement within types.\nF# 10 now raises an error when a Previous versions of F# accepted Now, this pattern raises error FS0058, forcing you to clarify your intent with proper module placement:<\/p>\n A deprecation warning now appears for bare sequence expressions that omit the Historically, F# allowed a special-case \u201csequence comprehension lite\u201d syntax where the Now, the compiler warns about this pattern and encourages the explicit form that clarifies semantics:<\/p>\n This is currently a warning, not an error, giving you time to update your codebase.\nThe explicit Attribute target validation will be enforced with this release across all language constructs.\nF# 10 validates that attributes are only applied to their intended targets by checking Previous versions of F# silently allowed attributes to be misapplied to incompatible targets.\nThis caused subtle bugs, such as test attributes being ignored when you forgot Now, the compiler enforces attribute targets and raises a warning when attributes are misapplied:<\/p>\n Compatibility:<\/strong><\/p>\n This is a breaking change that may reveal previously silent issues in your codebase.\nThe early errors prevent test discovery problems and ensure that attributes like analyzers and decorators take effect as intended.<\/p>\n This release brings a single improvement to the FSharp.Core library: support for Using Perhaps you started with code that awaited computations sequentially:<\/p>\n If you then wanted to change it to await them concurrently, you would typically use With F# 10, you can instead write a more idiomatic version using This combines the semantics of the second snippet with the simplicity of the first.<\/p>\n This release also introduces a new type subsumption cache to accelerate type checking and improve IDE responsiveness, especially in projects with complex type hierarchies.\nIn F# 10, the compiler memoizes the results of type relationship checks, reducing redundant computations and improving overall compiler and tooling performance.<\/p>\n Previously, the F# compiler would repeatedly perform expensive subsumption checks when dealing with large type hierarchies, such as those involving numerous numeric primitives or many interface implementations.\nThis could lead to noticeable latency during type inference and IDE operations, particularly in large solutions or during long editing sessions, consuming extra CPU and memory.<\/p>\n Now, the new type subsumption cache stores the results of these checks.\nWhen the compiler needs to determine if one type can be used in place of another, it first consults the cache.\nThis memoization avoids re-computing the same type relationships, leading to faster compilation and more responsive IntelliSense.<\/p>\n No code changes are required to benefit from this improvement; the performance gains are automatic.<\/p>\n F# 10 removes a long\u2011standing bit of friction with trimming F# assemblies:\nyou no longer have to hand\u2011maintain an When you publish with trimming enabled ( If you need full manual control you can still add your own substitutions file.\nThe auto-generation can be turned off with a property, like so: An exciting update for F# users looking to reduce their projects’ compilation times is the progressing stabilization of the parallel compilation features.\nStarting with .NET 10, three features: graph-based type checking, parallel IL code generation, and parallel optimization are grouped together under the Currently, this setting is turned on by default for projects that are using F# is a great scripting language, and we want to ensure that the tooling also supports that use case.\nThat is why we’re extending the With this release, you can simply use the Known issue caveat:<\/strong>\nAs of publishing this post, there is a known bug<\/a> that severely limits the benefits of using F# is developed as a collaboration between the .NET Foundation, the F# Software Foundation, their members and other contributors including Microsoft.\nThe F# community is involved at all stages of innovation, design, implementation and delivery and we\u2019re proud to be a contributing part of this community.<\/p>\n In the past year, we merged commits from 25 contributors.\nWe would like to thank all of you, as well as many others who filed issues<\/a>, raised and voted on language suggestions<\/a>, and contributed to language design<\/a>.\nIn particular, we explicitly call out some of the most active community contributors:<\/p>\n As is tradition in our release announcements, the contributor showcase section is where we celebrate some of our most impactful open-source community contributors.\nWhile our long-time contributor Jakub Majocha received a well-deserved shout-out in a .NET 8 announcement<\/a> two years ago, his outstanding work over the past year on the F# compiler has earned him one here in the F# release blog post.\nThis time, he is going to share a little about his approach to contributing to the repo:<\/p>\n Looking back at my PR history I see that most of them are fixes to things that I broke \ud83d\ude42\nThat’s why as a hobbyist I try to stick to contributions that have low risk of breaking something serious. For example I had a lot of fun making the tests run in parallel.\nI’m also always looking for low-hanging fruit, there still are quite a few. For example you can revive some unfinished PRs that were already almost done:\nType subsumption cache was one and the other was tail-call support in computation expressions – my first ever RFC implemented.\nI have an interest in tooling and its performance, so another surprising win that I’m very happy with is reducing StackGuard related slowdowns.\nI had a hunch about StackGuard impact on editor performance, and experimented for some time with various approaches.\nAdding some instrumentation to collect metrics was the most helpful here and the solution turned out to be very straightforward.\nI’d like to add huge thanks to the Amplifying F# collective for encouraging my attempts and sponsoring my Copilot subscription.<\/p>\n<\/blockquote>\n If you read it carefully, you might have noticed a teaser of an upcoming performance improvement that didn’t make it to this release, but we are very excited to bring to F# 11.<\/p>\n And just like Jakub, we would like to recognize Amplifying F#<\/a> for their invaluable support of community contributors.\nEfforts like theirs help make the F# ecosystem thrive.<\/p>\n Work on F# 11 is already under way: more performance wins, language\nimprovements, and tooling upgrades.<\/p>\n Go to our GitHub repo to jump into discussions<\/a>, help wanted issues<\/a> or good first issues for new contributors<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" Learn about new F# 10 language features, performance upgrades, and tooling improvements shipping with .NET 10.<\/p>\n","protected":false},"author":123807,"featured_media":58889,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[685,636],"tags":[7892,63,73,8085],"class_list":["post-58888","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dotnet","category-fsharp","tag-dotnet-10","tag-dotnet","tag-f","tag-f-10"],"acf":[],"blog_post_summary":" Learn about new F# 10 language features, performance upgrades, and tooling improvements shipping with .NET 10.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/58888","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/123807"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=58888"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/58888\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/58889"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=58888"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=58888"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=58888"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Language Improvements<\/h2>\n
1. Scoped warning suppression<\/h3>\n
#warnon<\/code> directive, which pairs with #nowarn<\/code> to enable or disable warnings within a specific code span.<\/p>\n\/\/ We know f is never called with a None.\nlet f (Some a) = \/\/ creates warning 25, which we want to suppress\n \/\/ 2000 loc, where the incomplete match warning is beneficial<\/code><\/pre>\n#nowarn 25<\/code> directive right above the function definition,\nbut without a matching #warnon 25<\/code>, this will disable the FS0025 warning in the remainder of the file,\nrisking the suppression of legitimate issues elsewhere.<\/p>\n#nowarn 25\nlet f (Some x) = \/\/ FS0025 suppressed\n#warnon 25\n \/\/ FS0025 enabled again<\/code><\/pre>\n#warnon<\/code>.\nThis directive will then apply until a matching #nowarn<\/code> or the end of the file.<\/p>\n#nowarn<\/code>\/#warnon<\/code> directives, leading to more predictable behavior.\nHowever, these are breaking changes that might affect your codebase when you update to F# 10.\nA detailed list of potential issues can be found in the RFC-1146<\/a>, but here are a couple of examples most likely to occur:<\/p>\n\n
#<\/code> and nowarn<\/code> is no longer allowed. <\/li>\n#nowarn<\/code> directive anywhere in a script applied to the whole compilation.\nNow, its behavior in scripts matches that in .fs<\/code> files, applying only until the end of the file or a corresponding #warnon<\/code>.<\/p>\n2. Access modifiers on auto property accessors<\/h3>\n
type Ledger() =\n [<DefaultValue>] val mutable private _Balance: decimal\n member this.Balance with public get() = this._Balance and private set v = this._Balance <- v<\/code><\/pre>\ntype Ledger() =\n member val Balance = 0m with public get, private set<\/code><\/pre>\nLedger<\/code> example above would be:<\/p>\ntype Ledger() =\n member Balance : decimal\n member private Balance : decimal with set<\/code><\/pre>\n3.
ValueOption<\/code> optional parameters<\/h3>\nValueOption<'T><\/code> representation.\nBy applying the [<Struct>]<\/code> attribute to an optional parameter, you can instruct the compiler to use ValueOption<'T><\/code> instead of the reference-based option<\/code> type.\nThis avoids a heap allocation for the option wrapper, which is beneficial in performance-critical code.<\/p>\noption<\/code> type for optional parameters, even when the parameter was absent.\nFor high-throughput scenarios or inner-loop object creation, this imposed unnecessary GC pressure.\nDevelopers working on performance-sensitive code had no way to avoid these allocations:<\/p>\n\/\/ Prior to F# 10: always uses reference option\ntype X() =\n static member M(?x : string) =\n match x with\n | Some v -> printfn \"Some %s\" v\n | None -> printfn \"None\"<\/code><\/pre>\n[<Struct>]<\/code> attribute on an optional parameter to leverage the struct-backed ValueOption<\/code> and eliminate allocations when the argument is absent:<\/p>\ntype X() =\n static member M([<Struct>] ?x : string) =\n match x with\n | ValueSome v -> printfn \"ValueSome %s\" v\n | ValueNone -> printfn \"ValueNone\"<\/code><\/pre>\noption<\/code> when you rely on existing pattern matching helpers, need reference semantics, or when the performance difference is negligible.\nThis feature strengthens parity with other F# language constructs that already support ValueOption<\/code>.<\/p>\n4. Tail-call support in computation expressions<\/h3>\n
return!<\/code>, yield!<\/code> or do!<\/code> appears in a tail position and,\nwhen the builder provides special methods, routes those calls to the optimized entry points.<\/p>\n\n
ReturnFromFinal<\/code>, the compiler will call it for a tail return!<\/code> (falling back to ReturnFrom<\/code> if the final variant is absent).<\/li>\nYieldFromFinal<\/code>, the compiler will call it for a tail yield!<\/code> (falling back to YieldFrom<\/code> if absent).<\/li>\ndo!<\/code>, the compiler will prefer ReturnFromFinal<\/code>, then YieldFromFinal<\/code>, before falling back to the normal Bind<\/code> pathway.<\/li>\n<\/ul>\n*Final<\/code> members are optional and exist purely to enable optimization: they allow builders to short-circuit continuations or otherwise relinquish resources early.\nBuilders that do not provide these members keep their existing semantics unchanged.<\/p>\ncoroutine {\n yield! subRoutine() \/\/ tail position -> YieldFromFinal if available\n}<\/code><\/pre>\ncoroutine {\n try\n yield! subRoutine() \/\/ not tail -> normal YieldFrom\n finally ()\n}<\/code><\/pre>\n*Final<\/code> methods, so builders that must remain compatible with earlier compiler versions should not assume those methods will be invoked.<\/p>\n5. Typed bindings in computation expressions without parentheses<\/h3>\n
let!<\/code>, use!<\/code>, and and!<\/code> bindings without wrapping the identifier in parentheses.<\/p>\nlet! (x: int) = fetchA()<\/code> was valid, but the more natural let! x: int = fetchA()<\/code> would cause an error.\nThis forced developers to use visually noisy parentheses even for simple type annotations:<\/p>\nasync {\n let! (a: int) = fetchA()\n and! (b: int) = fetchB()\n use! (d: MyDisposable) = acquireAsync()\n return a + b\n}<\/code><\/pre>\nlet<\/code> bindings:<\/p>\nasync {\n let! a: int = fetchA()\n and! b: int = fetchB()\n use! d: MyDisposable = acquireAsync()\n return a + b\n}<\/code><\/pre>\n6. Allow
_<\/code> in use!<\/code> bindings<\/h3>\nuse!<\/code> bindings, even when the resource value itself was never referenced.\nThis inconsistency with regular use<\/code> bindings forced developers to create throwaway identifiers like __<\/code> or _ignored<\/code> just to satisfy the compiler.<\/p>\n_<\/code>) now works in use!<\/code> bindings within computation expressions.\nF# 10 allows you to use _<\/code> directly when binding asynchronous resources whose values\nare only needed for lifetime management, without being forced to provide a named identifier.<\/p>\nuse<\/code>:<\/p>\ncounterDisposable {\n use! _ = new Disposable()\n \/\/ logic\n}<\/code><\/pre>\n7. Rejecting pseudo-nested modules in types<\/h3>\n
module<\/code> declaration appears indented at the same structural level\ninside a type definition, preventing a common source of confusion about module scoping.<\/p>\nmodule<\/code> declarations indented within type definitions,\nbut these modules were actually created as siblings to the type rather than being nested within it.\nThis indentation pattern frequently misled developers into believing they had created a nested module, resulting in unexpected scoping behavior:<\/p>\ntype U =\n | A\n | B\n module M = \/\/ Silently created a sibling module, not nested\n let f () = ()<\/code><\/pre>\ntype U =\n | A\n | B\n\nmodule M =\n let f () = ()<\/code><\/pre>\n8. Deprecation warning for omitted
seq<\/code><\/h3>\nseq<\/code> builder.\nF# 10 warns when you use bare range braces like { 1..10 }<\/code> or similar forms, encouraging you to use the\nexplicit seq { ... }<\/code> form for consistency with the broader computation expression model.<\/p>\nseq<\/code> keyword could be omitted.\nThis diverged from how other computation expressions work and created an inconsistency in the language:<\/p>\n{ 1..10 } |> List.ofSeq \/\/ implicit sequence<\/code><\/pre>\nseq { 1..10 } |> List.ofSeq<\/code><\/pre>\nseq<\/code> form improves code clarity and consistency with other computation expressions.\nFuture versions of F# may make this an error, so we recommend adopting the explicit syntax when updating code.<\/p>\n9. Attribute target enforcement<\/h3>\n
AttributeTargets<\/code>\nacross let-bound values, functions, union cases, implicit constructors, structs, and classes.<\/p>\n()<\/code> to make a function\nor analyzer directives failing to take effect, leading to confusing CI discrepancies:<\/p>\n[<Fact>]\nlet ``this is not a function`` = \/\/ Silently ignored, not a test!\n Assert.True(false)<\/code><\/pre>\n[<Fact>]\n\/\/^^^^ - warning FS0842: This attribute cannot be applied to property, field, return value. Valid targets are: method\nlet ``works correctly`` =\n Assert.True(true)<\/code><\/pre>\nFSharp.Core enhancement – support for
and!<\/code> in task expressions<\/h2>\nand!<\/code> in the task<\/code> computation expression.<\/p>\ntask<\/code> is a popular way to work with asynchronous workflows in F#, especially when interop with C# is required.\nHowever, until recently there was no concise way to await multiple tasks concurrently in a computation expression.<\/p>\n\/\/ Awaiting sequentially\ntask {\n let! a = fetchA()\n let! b = fetchB()\n return combineAB a b\n}<\/code><\/pre>\nTask.WhenAll<\/code>:<\/p>\n\/\/ Use explicit Task combinator to await concurrently\ntask {\n let ta = fetchA()\n let tb = fetchB()\n let! results = Task.WhenAll([| ta; tb |])\n return combineAB ta.Result tb.Result\n}<\/code><\/pre>\nand!<\/code>:<\/p>\ntask {\n let! a = fetchA()\n and! b = fetchB()\n return combineAB a b\n}<\/code><\/pre>\nPerformance & Tooling<\/h2>\n
Type subsumption cache<\/h3>\n
Better trimming by default<\/h3>\n
ILLink.Substitutions.xml<\/code> file just to strip large F# metadata resource blobs (signature\/optimization data) that aren’t needed at runtime in the final application.<\/p>\nPublishTrimmed=true<\/code>), the F# build now auto\u2011generates a substitutions file that targets the tooling\u2011only F# resources.\nThe result: smaller output by default, less boilerplate, and one fewer maintenance hazard.<\/p>\n<DisableILLinkSubstitutions>false<\/DisableILLinkSubstitutions><\/code>.<\/p>\nParallel compilation in preview<\/h3>\n
ParallelCompilation<\/code> project property.<\/p>\nLangVersion=Preview<\/code>, and we plan to turn it on for everyone in .NET 11.\nBe sure to give it a try and see if it speeds up your compilation.\nHowever, if you want to opt out but still enjoy other preview features, then set the ParallelCompilation<\/code> to false.<\/p>\nTypecheck-only mode for scripts<\/h3>\n
--typecheck-only<\/code> compilation flag to also work for .fsx<\/code> scripts, where it’s arguably the most beneficial.\nIn F# 9 and earlier, there was no easy way to validate syntax and type correctness of a script without running the code, which would often produce side effects.<\/p>\n--typecheck-only<\/code> flag while invoking fsi<\/code> to typecheck the script without execution.\nThis feature makes it easy to add CI gates that will be able to catch script rot in your codebase.<\/p>\n--typecheck-only<\/code> with scripts that include others via #load<\/code>.\nIn that case type checking will conclude prematurely after processing the first loaded source file. However, the fix has already been implemented and will be included in the upcoming patch release 10.0.200.<\/p>\nThanks and acknowledgements<\/h2>\n
\n
#nowarn<\/code> feature design and implementation.<\/li>\nContributor showcase<\/h2>\n
\n
What’s next?<\/h2>\n