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. https://github.com/dotnet/fsharp/issues/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 https://github.com/dotnet/fsharp/pull/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!

[dsyme]

I added https://github.com/dotnet/fsharp/issues/8654 to the list

[smoothdeveloper]

Related: #11564 (remove setter for init only properties)

[smoothdeveloper]

the issue would be C# >= 7.0 compatibility ideally, umbrella issue of what is missing so it doesn't break expectations.

Is there an issue already for having { myCSharpRecord with ... } support in F#?

[KevinRansom]

@smoothdeveloper I don't think so, but it is a neat idea.

[jcmrva]

Is there any chance generic attributes can be included?

[NinoFloris]

Originally posted in https://github.com/dotnet/fsharp/pull/13119, more appropriate to post it here.

Will we also be able to produce interfaces with abstract static members in the near future?

I've already had great success replacing a few kloc boilerplate infra for object mapping with abstract static interface members in C#. This also brought a measurable efficiency gain over the previous approach of late binding lambdas stored in a dictionary keyed by source/dest type pair compared to the simplicity of an abstract static constrained call.

I can similarly imagine how it would allow a fair few SRTP code patterns to be replaced with something reflection free, and fully supported at the IL level in F# as well.

[vzarytovskii]

Originally posted in https://github.com/dotnet/fsharp/pull/13119, more appropriate to post it here.

Will we also be able to produce interfaces with abstract static members in the near future?

I've already had great success replacing a few kloc boilerplate infra for object mapping with abstract static interface members in C#. This also brought a measurable efficiency gain over the previous approach of late binding lambdas stored in a dictionary keyed by source/dest type pair compared to the simplicity of an abstract static constrained call.

I can similarly imagine how it would allow a fair few SRTP code patterns to be replaced with something reflection free, and fully supported at the IL level in F# as well.

It's not a goal for current PR, and likely not for the Fall release (since there is a bunch of work that needs to be done besides this feature and there are only a few of us for now :)).

I wouldn't mind supporting it in future if @dsyme sees it fit for F#.

[dsyme]

I wouldn't mind supporting it in future if @dsyme sees it fit for F#.

We should support this

[333fred]

Another point on the list would be CompilerFeatureRequiredAttribute. This attribute is similar to a modreq where anything that is attributed with such an attribute with an unknown string should be marked as unsupported by F# and access should be blocked. Admittedly, F# does not honor modreqs today, but it would be good to add this support if you can.

[vzarytovskii]

Another point on the list would be CompilerFeatureRequiredAttribute. This attribute is similar to a modreq where anything that is attributed with such an attribute with an unknown string should be marked as unsupported by F# and access should be blocked. Admittedly, F# does not honor modreqs today, but it would be good to add this support if you can.

Thanks, Fred, I've added it to the original list. One question by "access should be blocked`, do you mean, we should just emit a compilation error if user is trying to use such feature?

[333fred]

Yes. In C#/VB, if we see the user using a thing with this attribute, we error and say "'location' requires compiler feature 'attribute string', which is not supported by this version of the C# compiler."

[DalekBaldwin]

I've been playing around with static abstracts in F# with the latest release, but while attempting to get interop working, I stumbled on a very troubling discussion: https://github.com/dotnet/csharplang/issues/5955

Apparently the decision has been made to scale back the scope of this feature in C#, eliminating some of the most promising use cases, perhaps until additional annotations are provided to restrict their use. Has this affected design decisions in F#? I haven't seen it mentioned anywhere here.

You can still compile these patterns in the latest version of C# with the right combination of magical incantations, and interop them with the latest F#, but I worry about using them if they may be lost in the future.