Support for static abstract members in interfaces

[dsyme]

C# and .NET 7 are adding support for static abstract members in interfaces

RFC: https://github.com/fsharp/fslang-design/blob/main/FSharp-7.0/FS-1124-interfaces-with-static-abstract-members.md
RFC: https://github.com/fsharp/fslang-design/blob/main/FSharp-7.0/FS-1083-srtp-type-no-whitespace.md

C# design: dotnet/csharplang#4436

Work has begun to implement this feature in F# dotnet/fsharp#13119

This is a placeholder suggestion to track this issue

[tjwald]

How are SRTP constraints going to change after this feature is implemented?
According to my understanding, there is now runtime support for static generic method invocation. Will there be an update to codegen related to SRTP functions in F#?
@dsyme

[vzarytovskii]

How are SRTP constraints going to change after this feature is implemented?
According to my understanding, there is now runtime support for static generic method invocation. Will there be an update to codegen related to SRTP functions in F#?
@dsyme

This is one of the points being discussed - should we support something like ^T.StaticProperty or should it be part of another change (simple SRTP call convention). Regarding the constraints themselves, i don't think there will be any change (since we already support calling for static members).

[tjwald]

Actually I was thinking more in the line of relaxing the inline requirement for SRTP for now runtime supported SRTP.
I definitely would want it to be T.property! Its what is most intuitive for f# beginners in my opinion.

[vip-ehowlett]

Super excited about this. This along with named SRTP collections will help simplify a lot of my library code.

[matthewcrews]

I read over the RFC. How bad would it be for F# to just not consume this? I ask because it looks like there are large number of downsides to this feature and there are plenty of other things that can be done to enhance F#.

[smoothdeveloper]

@matthewcrews I think this is not an option, the BCL is going to use this pervasively.

One option would be to not be able to define the interfaces with such members themselves, but it is unlikely to be the hardest part of the implementation, which I'd expect to be in the type checking and inference.

Not supporting it, especially if it ships soon, is going to really split F# appart from the BCL, which I think will hurt F# itself farther.

I hope @vzarytovskii & @dsyme can make it happen and bullet proof for dotnet 7 release 🤞.

[matthewcrews]

Is this going to have a significant impact on Runtime performance and Compiler performance? It would seem that it would.

[smoothdeveloper]

Runtime performance I was wondering about how option B performs once the JIT / AOT does the work, if it is basically the same as concrete implementation call?

C# has the option to not have the code duplication or delegating call, through implicit interface implementation.

For compile time performance, it is not going to help, member resolution will need to scan all interfaces and making sure there is no ambiguity, or report an error.

There is inherent tension between how BCL and CLR evolves (the OO & Scala way) and idioms that F# has in place: no way to implement interface implicitly is the one which hurts most for this feature IMO.

[Tarmil]

Runtime performance I was wondering about how option B performs once the JIT / AOT does the work, if it is basically the same as concrete implementation call?

C# has the option to not have the code duplication or delegating call, through implicit interface implementation.

Doesn't C#'s implicit interface implementation compile down to the same as option B?

[smoothdeveloper]

@Tarmil, not that I know much, trying with sharplab, with implicit interface implementation (but not related to IWSAM), the IL can avoid callvirt, and also less IL code in the output.

F# can't do this without introducing ability to implement interface implicitly, AFAIU.

using System;
class AAA{
    static void AA< T >(T m)  where T : IHasM {
      Console.WriteLine(T.MM() + m.M());
    }
    static void A(){
      C c;
      Console.WriteLine(c.M());
      IHasM h = c;
      Console.WriteLine(h.M());
//      AA<C>(h);
      AA<C>(c);
    }
}
public interface IHasM {
   int M ();
   static virtual int MM(){return 2;}
}
public struct C:  IHasM {    
    //int IHasM.M() { return this.M();}
    //int IHasM.M() { return 2;}
    public int M() { return 1; }
    public static int MM(){return 3;}
}

https://sharplab.io/#v2:EYLgtghglgdgNAFxFANgHwAICYCMBYAKGwAIBBcgb0OJuIxwDY6AWM0gHmIBViA+ACh5gAlDQDuACwCmAJyndiIYgEkAEhADOAWWJUCtWvQCcggHRat/UQGpiYc1eEBuarQC+rmvSYZWpK3oGNADCxADGLvpBxvxhDsLOnrRqmjoSxAC84ZFBdDgmEvGJBAD0Jbnk7MECEsUVHNWxde6EHkQAzMSwCLIAZhBh8inaup7dxDpWOV6MxABuUDIIAK4QKF0wCBOWwhQYAOzEWE5tbRidGggyy2FbwUoq6iMUBkll48Na8bp0hwgSUA08RObxKHyeXx2PwORxBUS8nXGUJeMJwTmIbQM5zyTCROz2h3acLaQA===

[vzarytovskii]

Was implemented

[edgarfgp]

@vzarytovskii will this also closes #668 ?