[.Net Native] F# Support

[charlesroddie]

[2018-12-06 update] F# UWP apps are releasable via the Windows Store. #6055 (comment)

[2018-06-17 update] UWP apps are compiling and running. More progress by the community in the last 4 days than Microsoft made in 3 years. The main issue is sprintf and we are looking into workarounds.

Problem

F# libraries cannot be used to create native UWP store apps. This results from the lack of F# support in the .NET Native UWP AOT compiler, which is required for publishing UWP store apps. In this post UWP will mean native UWP, i.e. compiled to IL or machine code.

Why support is needed

1. Windows application programming.
   a) UWP is actively developed (the platform itself and 3rd party components), unlike WPF.
   b) UWP also allows AR/VR and XBox apps, and Windows 10 IoT.
2. F# becomes toxic for cross-platform applications or controls that must support UWP.
   a) Xamarin.Forms F# developers end up without Windows app support.
   b) Creating Xamarin.Forms controls in F# for general consumption is effectively ruled out since UWP support is expected.
   c) Xamarin.Forms developers must avoid using .Net libraries if they are written in F#.

There has been huge user demand for this, with 1500+ votes for Add F# support for .NET Native and 2000+ votes for F# support in .Net native for UWP when those were active. This thread is a continuation of F# Support in .NET Native and UWP.

Status of work

Unfortunately users outside Microsoft cannot work on .Net Native. Microsoft has promised support:

2015-10 @crutkas: We are committed to bringing F# support to .NET Native... we’ve been working on .NET Native support for more advanced .NET IL code, like tail call instructions and complex generic types

2016-07 @cartermp: We get recent internal builds of the toolchain that we run tests on, we add tests to try and see what else we can break, and we report issues. These issues get logged into the .NET Native engineering backlog as soon as they come up.

2017-08 @cartermp: We'll remain subject matter experts for the UWP team to work with on .NET Native support, push for F# on their priority list after their .NET Standard support is completed, and we'll also contribute in identifying problems that need to be solved for proper .NET Native support.

Unfortunately the issue appears to have slipped between Microsoft teams with no-one currently working on it.

Technical issues

Two hard issues have been mentioned from the beginning, but the first seems to have been a red herring, and the second may have been fixed.

Tailcall support
2016-16-07 @dsyme: Yes, it's feasible for tailcalls just to be ignored in first-cut support. UWP Native would just have to ignore the tailcall prefix.

Generics
2017-09-04 @KevinRansom: I'm pretty sure the nested generics got fixed.

There is no public information about other issues and therefore it is not publicly known what is blocking F# usage.

What the community can do

Test .Net Native and CoreRT

CoreRT testing is in progress. It is now possible to test .Net Native. See @DjArt 's post here.

You can use the scaffolding here to test .Net Native and CoreRT. The F# cheatsheet works and we are starting to test the F# test suite. You can also try your UWP/Xamarin Forms apps. Generally avoid printf etc. and ToString() on F# record types and discriminated unions.

Please report issues in this (CoreRT) repo. If issues in .Net Native can be fixed in CoreRT, the fixes can probably be moved over into .Net Native.

Workarounds

• F# can be used to create non-Store UWP apps that are sideloaded onto Windows PCs that are in "developer mode".
• F# can be used to create Store apps using non-UWP technology (using desktop bridge with e.g. WPF or javascript transpliation with e.g. Fable/React Native).
• Xamarin Forms has a preview of WPF support. Whether this becomes a viable platform depends on support by 3rd party controls.
• (Speculative) In the .Net Core 3.0 timeframe, UWP controls can be used in WPF apps. Presumably .Net Native is not required. We may be able to create a store app using WPF (desktop bridge) hosting a UWP app.

[charlesroddie]

@jkotas @MichalStrehovsky Can you comment on the CoreRT bit? Will getting F# support in CoreRT make .Net Native support much easier? If that's true I'm sure we can get at least F#/CoreRT testing going quite rapidly.

[forki]

While I'd love to see F# support for .NET Native I think it's not needed for UWP.
If you really want to do that then you can use the workaround with Fable and React Native.

[zpodlovics]

Take a look at this, last time I checked the trivial helloworld example at least compiled:
#5648

However a "working" helloworld nowhere near what's needed to have real .NET Native / CoreRT support for F#. What is the current status of tailcalls in .NET Native and in CoreRT? The next project could be port the F# testsuite to CoreRT. Unless radical changes, at progress rate, you'll probably better if you learn everything and write your own compier for F#...

[forki]

regarding tailcalls: fable shows that this is not really needed (at least a lot can work without that optimization).

[martinsuchan]

@forki Depends what's your definition of UWP. As the original comment says in the Workarounds, it's possible to use F# in Desktop WPF/Xamarin apps and publish this app using Desktop Bridge into Microsoft Store. In a similar way it's possible to use F# and transcompile it into JavaScript together with React Native.

But the goal of this issue is full F# support in .NET Native UWP apps, without Desktop Bridge or JavaScript.

[forki]

what I'm trying to say is: this shouldn't be framed as UWP issue.

[7sharp9]

Xamarin mobile does not output tail calls either, its always been recommended to turn that option off as it has no effect.

[charlesroddie]

@forki I have added a working definnition of UWP to the OP, distinct from "Store" which includes JS and desktop bridge. If you don't like this definition just read "native UWP" where UWP is written and everything should make sense. I put Fable and React Native explicitly in the workarounds.

[Mike-E-angelo]

Really nice work with this post here, @charlesroddie. Thank you for taking the time to write it and for considering all the issues surrounding it. 👍

[jkotas]

Can you comment on the CoreRT bit? Will getting F# support in CoreRT make .Net Native support much easier?

Yes, it would make it somewhat easier. .Net Native shares many CoreRT parts. We have issues #2057 or #3929 opened about it.

If you have feedback about F# support for UWP specifically, the uservoice issues are better place to comment on it than this repo.

[Noemata]

F# was (and still could be) a cool way to develop XAML based software solutions. UWP is the XAML future of Windows, with Winforms (pre-XAML), WPF and Silverlight all being dead ends at present. As things stand F# has no future on Windows. It's really that stark and that stupid. Any suggestion that desktop bridge is a viable option is like saying hydrogen filled balloons are a viable way to travel. Yes, viable if like going slowly, in whatever direction the winds are blowing and plan on eventually blowing up.

[forki]

like saying hydrogen filled balloons

... Meanwhile others just ship apps happily...

[touseefbsb]

Functional programming seems to be an improved revolution in programming world ( I may be wrong ) and if we can incorporate that into uwp apps I think it would be great, I dont care whether F# support is brought for uwp or maybe c# 8 gets all functional features which F# has, ultimately making it easier for both world, maybe then f# developers can start using c# as well and united the .net community under 1 language which can do it all.