Tracking Issue for C# 11.0 Interop for F# 6.1/7.0

[KevinRansom]

Okay we need an issue to track F# language updates for the next release.

The target is to release by Fall 2022 --- so it's going to be a small set of features, this is not an ordered or prioritized list

Feel free to discuss and add suggestions here in this thread.

1. Support for consuming Interface Static Methods - C# 10.0 feature
2. Required property/field: C# 11.0 feature
3. Ref fields C# 11.0 feature
4. User defined check operator [C# 11.0 feature] (https://github.com/dotnet/csharplang/blob/main/proposals/checked-user-defined-operators.md?rgh-link-date=2022-02-10T19%3A05%3A24Z)
5. Relaxing shift operator signature requirements - C# 11.0 feature
6. Unsigned right shift operator (>>>). C# 11.0 feature
7. Honor new properties on ObsoleteAttribute for .NET 5 #8654
8. Support CompilerFeatureRequiredAttribute, more info.

Background: we believe we need to do a good job supporting this style:
https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/static-abstract-interface-methods

/cc @dsyme , @KathleenDollard , @jonsequitur , @vzarytovskii , @baronfel

[cartermp]

I think (1) is the biggest one, with (2) probably also being a nice-to-have. The rest I could see not doing any work for.

[smoothdeveloper]

related on dotnet/fsharp: #1254, #2503
related on dotnet/roslyn: !!???! (is there a matching ticket, for F# 1.0 interop on C# & VB.NET side?)
related on CLR languages: profit

[kerams]

Is nullness checking off the table for .NET 7? Finishing #11394 would also be nice. Otherwise agreed on 1.

(This is perhaps besides the point, but personally I'd rather see finishing ref assembly support, parallel type checking and IL gen than new language features for this release.)

[smoothdeveloper]

Around nullness checking, performance and F# codebases that are already null safer than industry average since V1.

Is there going to be a "experimental F# SPO optimizer" version, that is going to elide, desugar Option and ValueOption, leveraging flow analysis and type checker improvements related to nullness checking, into tighter and monorphized code?

• What is state of the art, in this regard, in other compilers (for example: Rust, does it optimize Option and Result away in some manner?),
• theoritically, would the JIT able to magically do this, if the magic was baked into meta data (CLR attributes) that the runtime/JIT infrastructure would process, with such aim (for ALL CLR languages), leaving it up to compiler implementers to leverage the idioms defined by the runtime team

[KevinRansom]

@kerams nullness checking is my personal biggest want, I find dealing with nulls only because of C#/VB interop a pita. However, that is on @dsyme and he is a busy little fellow.

[vzarytovskii]

@kerams nullness checking is my personal biggest want, I find dealing with nulls only because of C#/VB interop a pita. However, that is on @dsyme and he is a busy little fellow.

Probably should set up main auto-merging for the nullness branch, so it will at least have all the latest changes there.

[dsyme]

I put the above into priority order - (1) and (2) are necessary to do.

The nullness branch is up-to-date, lots of work needed there though

[KathleenDollard]

I want to add one that is .NET 7, rather than C#, but it is driven by .NET, so may belong on this list: trimmability of FSharp.Core. I would hate to see F# cut out of Native AOT.

Other than that, 2 (required) also includes respect for init scope. I would have to put that first because we do the wrong thing (ignoring an expected contract) rather than just not being able to consume. But statics are such an important feature that if we cannot do these two things, I will definitely cry.

[cartermp]

Agreed @KathleenDollard, F# should be a part of the AOT story with no more caveats that C# (within reason!)

[En3Tho]

I'm sorry if my question is off topic, but is there a issue like this but for F# specifically?

Like this is "What features of .Net and C# F# wants to support for .Net 7 release". Is there a "What features F# wants for itself for .Net7 release" one?

Again, sorry for off topic. It's just that I find it quite hard to find information about F# roadmap.

[smoothdeveloper]

knowing:

• considerations allegedly taken for tailoring the tree shaking story
• the team behind the compiler (apt to take any ticket from runtime and deal with it, maybe it requires a special branch in the code generation of some constructs?)
• where the F# language journeyed in terms of "100% dotnet language player", especially with windows universal and AOT without mono

The endorsement of @KathleenDollard on this particular topic is a very good indication this is headed the right way, I hope it helps the people who needs it badly, whenever it is viable to ship in the dotnet sdk, from Microsoft perspective, and that in meantime, it carries the effect on perception about future of the language of those that got impacted by earlier decisions.

Congratulations!