Bump F# to 4.7

[auduchinok]

Please update the F# compiler bundled to Mono distribution.

It's probably finally the time to have it updated after the 4.5 update celebration time. #10919 (comment) :)

[marek-safar]

/cc @steveisok

[abhsrivastava]

Can you please prioritize this. Anonymous records are so cool

[auduchinok]

@cartermp Is there a chance the F# compiler in Mono distribution could be aligned with .NET Core SDK releases?

[cartermp]

Not that I'm aware of. We just produce the bits; Mono infrastructure still needs to do dependency uptake. I don't know how that's handled on the Mono repo.

[charlesroddie]

Will the situation remain like this (difficult manual updates) until .Net 5 comes out?
Presumably when .Net 5 comes out this problem goes away?

Currently the average F#/Xamarin user will have no idea what F# features can be used. You have to search through a lot of github issues and be a compiler expert to work out the current status.

Until the underlying problem is fixed we need an F# language status showing the latest F# version that can be used on different systems. I gather this is currently: VS2019: 4.7. VS4Mac: 4.5. Mac builds without VS4Mac: 4.5.

Related issue which presumably affects a disjoint set of F# mac and/or Xamarin usage: mono/monodevelop#8864

[nosami]

cc @dsyme

[nosami]

Not that I'm aware of. We just produce the bits; Mono infrastructure still needs to do dependency uptake. I don't know how that's handled on the Mono repo.

Mono builds F# from the fsharp/fsharp repo. That has since been deprecated in favor of dotnet/fsharp (fsharp/fsharp#903)

F# 4.7 from dotnet/fsharp doesn't work under Mono. Mono isn't targetted by the build scripts - only netcoreapp2.1 output is produced.

[dsyme]

The situation is unsatisfactory, though I'm not certain the best path. It depends

1. on the Xamarin/mono roadmap

2. the level of difficulty in preparing an F# 4.7 for mono. (I suspect it would be a lot less work than F# 4.5, just integrating across the non-project-file changes in src/fsharp into fsharp/fsharp, but it would need to be done carefully)

[akoeplinger]

I looked at this a month ago and was able to get it mostly working by continuing the work done by @baronfel in baronfel/fsharp#1 and merging in master, I pushed it to https://github.com/akoeplinger/fsharp/tree/mono. There are some parts that I don't fully understand so it probably needs more tweaks.

Unfortunately another task preempted me from finishing this for now.

[baronfel]

Oh that's great news @akoeplinger! I think I had got most of the way to a working build, but the specifics of recreating the installed binaries tree during make install eluded me. I wasn't sure what mono was still supporting for the old F# build targets vs. going all-in on requiring fsharp.core via packagereference like the new SDK does.

[vshapenko]

Any updates on issue?

[vshapenko]

@dsyme , may you take a look at this issue? Looks forbidden and forgotten for unknown reasons

[jwosty]

It would be great if this could be resolved. Having mono be 2 F# versions behind, using the compiler that was current almost 2 years ago is not a good look. The result is that its simply impossible to use modern F# in Xamarin or mono applications... This is sorely needed. My current fix is to rip out anonymous records from my code in order to get it to build on macOS. 😢

[charlesroddie]

Reporting on slack discussions. It turns out the problem is rather contained.

1. The problem is isolated to mono builds on MacOS and will go away with dotnet5. Mono/mono has the problematic fsharp/fsharp references under MacSDK. dotnet/runtime doesn't have any fsharp reference except in tests (so the parts of mono that were merged in don't contain the problem).
2. @TimLariviere reports that you can build netstandard F# 4.7 projects using dotnet build on Mac. So in Xamarin.Forms, if you have the platform-specific Xamarin projects in C# (or F# 4.5) you can use F# 4.7 features in referenced netstandard projects with a dotnet build pre-build step in the platform projects.

[vshapenko]

@charlesroddie The question is, how to be with projects targeting android or ios using f# 4.7. For now, we are forced to build our ios applications on windows using mac as pairing counterpart. Does not looks solid when i cant build an ios app on MacOS itself. I understand reasons about upcoming net 5 (in November), but this story has begun long ago. No blames, but it looks like a problem nobody responsible wants to solve by unknown reasons.

[charlesroddie]

@vshapenko You seem to be replying to the answer (point 2 above) with the question. Usually it's the other way around!

[vshapenko]

@vshapenko You seem to be replying to the answer (point 2 above) with the question. Usually it's the other way around!

That does not solve the problem if ios/android project written using f# 4.7 features. And yes, this is a (possibly) working solution. But anyway , current state of f# support in mono for macos brings much pain for those who are developing for ios.

[charlesroddie]

Usually there is minimal code in platform-specific projects if using Xamarin.Forms. Understood that it may not resolve the problem for devs using Xamarin.iOS and Xamarin.Android directly instead of Forms. But for a large majority of F#/Xamarin use it's a workaround that should address the problem until Nov when dotnet5 comes out. Main pain point is that you need to know about this thread and put in a pre-build step.

[Dolfik1]

Usually there is minimal code in platform-specific projects if using Xamarin.Forms. Understood that it may not resolve the problem for devs using Xamarin.iOS and Xamarin.Android directly instead of Forms. But for a large majority of F#/Xamarin use it's a workaround that should address the problem until Nov when dotnet5 comes out. Main pain point is that you need to know about this thread and put in a pre-build step.

I tried to build shared project with dotnet build command and then build iOS project from VS for Mac, but got this error:

[charlesroddie]

I added "Or F# 4.5" based on this conv:

@charlesroddie Do we know what happens if you have project A using F# 4.7 features, and dotnet build it, and reference it from an F# Xamarin.ios project which uses F# 4.5 features, and build the latter on a Mac? (edited)
@cartermp If A exposes something that F# 4.5 doesn't understand, it won't work (just typical forwards-compatibility woes). But otherwise it should work, since things are binary compatible. I can publish a NS 2.0 library with the latest preview of the F# compiler and you can consume that from a Xamarin app

Does "expose" means forming part of the public API? So the netstandard libraries can contain anonymous records that are private/internal/locally scoped?

We don't use F# platform-specific projects so can't test this ourselves.

[TimLariviere]

I guess, as long as you don't directly interact with F# > 4.5 features in your F# Android/iOS projects, it will work.

I have an example here: https://github.com/TimLariviere/Fabulous/blob/a16badd359de2c270c60ba467c8f284b20da9187/Fabulous.XamarinForms/samples/CounterApp/CounterApp/CounterApp.fs

I'm using anonymous records and open static classes in a .NET Standard 2.0 project.
It builds with dotnet 3.1.300, then Android/iOS builds and runs fine. (don't rebuild though, otherwise MSBuild will try to build the shared project itself and it will fail).

[Dolfik1]

I added "Or F# 4.5" based on this conv:

@charlesroddie Do we know what happens if you have project A using F# 4.7 features, and dotnet build it, and reference it from an F# Xamarin.ios project which uses F# 4.5 features, and build the latter on a Mac? (edited)
@cartermp If A exposes something that F# 4.5 doesn't understand, it won't work (just typical forwards-compatibility woes). But otherwise it should work, since things are binary compatible. I can publish a NS 2.0 library with the latest preview of the F# compiler and you can consume that from a Xamarin app

Does "expose" means forming part of the public API? So the netstandard libraries can contain anonymous records that are private/internal/locally scoped?

We don't use F# platform-specific projects so can't test this ourselves.

We have referenced project with anonymous records, but they do not used in iOS project

[jwosty]

I do want to clarify why this is an issue without a solution for me in particular right now, today. I have a cross-platform application that does audio processing. There is a huge chunk of shared code between platforms targeting .Net Standard, and so that bit could theoretically use F# 4.7 with @charlesroddie 's approach. However I do end up with large chunks of code that directly use the Xamarin.Mac bindings to Apple's CoreAudio APIs, and so those bits have to be dependent on whatever version of F# Xamarin.Mac works with. It sounds like this will go away with .Net 5, at which point (AFAIK) I will be able to use .Net 5 + Xamarin.Mac + F# 4.7, is that correct? That just means I have to wait until .Net 5 is release. Which I can deal with since it's supposed to come out soon (a few months).

[KirillOsenkov]

@marek-safar this is a very impactful issue, we get tons of feedback on this

[charlesroddie]

I'm figuring the status of this, in public in case it interests anyone on this thread.

The F# 5.0 update is in:

• mono-6.12.0.106 tagged on 27 Oct: https://github.com/mono/mono/releases/tag/mono-6.12.0.106
• VS for Mac 8.8.2 (8.8.2.41) released November 24, 2020 https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2019-mac-relnotes

This documentation PR for azure pipelines/github actions, created 2 days ago and just merged, includes these updates for VS for Mac and mono: actions/runner-images#2183 . Assuming this is correct, this is now deployed to azure pipelines.