F# language and tools update for Visual Studio 2017 version 15.6
With the release of Visual Studio 2017 version 15.6, we’re excited to share updates to the F# language and core library, F# tooling in Visual Studio, and infrastructure updates that concern OSS contributors. Let’s dive in!
F# language and core library updates
Some foundational changes for the F# language and core library have been made, in addition to smaller behavioral language changes and added features to FSharp.Core.
We have drafted and implemented a versioning change for F# moving forward. There are two major changes involved:
- Decoupling tooling artifact versioning for F# language versioning, allowing all tools to rev semantically and align with the multiple release trains for different products that we must deliver on, rather than artificially align with an F# language version.
- Aligning the F# language, FSharp.Core binary, and FSharp.Core package to the same versioning scheme, thus creating a consistent versioning model for these assets.
To do this, we will rev the F# language version from 4.1 to 4.5 when Visual Studio 2017 version 15.7 releases, as documented in the linked RFC. We will have a separate blog post which reiterates this change when it is released.
F# Language updates
Numerous bug fixes and smaller improvements have been made in the F# compiler, which included contributions from the F# OSS community.
The primary behavioral change for the F# language in this update is a backwards-compatible change to make F# tuple and System.Tuple types 100% synonymous:
Now that F# tuples and System.Tuples are synonymous, we emit a warning when accessing the .Item and .Rest properties from a System.Tuple:
This fixes inconsistencies with how these two types interact and fixes a regression introduced in VS 2017 version 15.4.
Additionally, some recent regressions in inference order for Statically Resolved Type Parameters (SRTP) have been fixed, and the behavior has been stabilized. Moving forward, the current behavior for SRTP is cemented. This advanced and less-used area of the language is quite touchy as far as the compiler is concerned, and we feel stability is the most important thing moving forward.
F# Core Library updates
The F# Core Library, known as FSharp.Core is distributed via the NuGet package. We include the binary in Visual Studio and a reference to the package in our .NET Core SDK support. The following additions are now available:
- Support for IReadonlyList and IReadonlyDictionary in relevant F# collections, by Saul Rennison.
- Support for Async.StartImmediateAsTask, added by Onur Gumus.
- Support for NativePtr.toByref, added by mjmckp.
- Support for Seq.transpose/List.transpose/Array.transpose, by Patrick McDonald.
- The IsSerializable property is now present on F# types for the .NET Standard version of the library.
This smaller set of improvements is an example of the sorts of things we’re looking to have in future FSharp.Core releases.
F# tooling improvements in Visual Studio
The largest focus for us recently has been in improving the development experience for F# with .NET Core SDK projects. This started with initial support in the 15.5 release, where we also made F# installed by default in Visual Studio 2017 wherever .NET Core is required. We have more updates to share now.
With the 15.6 release, we’ve focused on bringing up project support for .NET Core SDK-based projects to have full file ordering and folder support:
If you select Add Item on the project node, the file will be added to the top of the list rather than the bottom. If you do this on a folder node, will add it to the top of the list underneath the folder. This fixes a long-standing issue for newcomers where newly-added files which weren’t moved up the list could lead to a compiler error. Add Above/Add Below work as they do in legacy F# projects.
We have one final bit of functionality to implement: initial ordering for a file which has been pasted in. It will currently add the file to the bottom of the list. We are targeting the next release of Visual Studio for this.
Additionally, we have added support for multitargeting.
You can toggle the multitargeting context and get IDE features for a particular target with the Navigation Bars dropdown:
With proper file ordering, folders, and multitargeting support, we’re declaring .NET Core SDK project types as fully supported. In a future release, we’ll also have ASP.NET Core templates with optional Docker support added as a project type you can create with File | New Project.
To see the full list of F# changes going into VS 15.6, see the release notes.
A view into the feature-rich IDE experience for F#
Throughout the year, many IDE features have made it into Visual Studio through open source contributions. Here are some of our favorites:
Go to Definition by clicking on symbols in QuickInfo, by Jakob Majocha:
Find all References and Inline Rename across projects, by Vasily Kirichenko:
Completion for items in unopened namespaces, by Vasily Kirichenko:
There are too many amazing features to talk about in a single blog post. You’ll have to explore them yourself! It’s exciting to see the advancements made in the past year, and we look forward to seeing what the next year will bring in Visual Studio. To get started, check out the official docs.
Open source infrastructure
Finally, we’ve made sweeping improvements to our infrastructure and paid off years of technical debt. We’re not done yet, but we’re quite excited about a few things that impact OSS contributors:
- Nightly builds can now be produced in about an hour, so you can see new features very quickly.
- We have a new nightly feed for preview versions of F# tools for Visual Studio.
- All localization files have been made open source (moved from an internal repository), and improvements to translated files can be made directly on GitHub now.
- We removed our dependency on the Windows 10 SDK and are close to removing all machine state dependencies from our build, with the goal of allowing you to build any part of the repository after running the build script after a clone.
- We now use a bot to merge changes across concurrent shipping branches so that we can more easily detect any dependency issues for future releases.
- We now build the F# Compiler Service project as a part of our CI, thanks to Steffen Forkmann
We’re continuing to invest in our infrastructure to keep up with the advancing world of multiple IDEs and SDKs which ship releases on different schedules. We’re also excited to further simplify OSS development by removing all machine state dependencies.
We’re very excited about these F# updates moving forward, and we look forward to sharing more updates about F#, the entire F# tooling experience, and the greater F# ecosystem soon. Happy F# coding!