-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for static abstract members in interfaces #1151
Comments
How are SRTP constraints going to change after this feature is implemented? |
This is one of the points being discussed - should we support something like |
Actually I was thinking more in the line of relaxing the inline requirement for SRTP for now runtime supported SRTP. |
Super excited about this. This along with named SRTP collections will help simplify a lot of my library code. |
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#. |
@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 🤞. |
Is this going to have a significant impact on Runtime performance and Compiler performance? It would seem that it would. |
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. |
Doesn't C#'s implicit interface implementation compile down to the same as option B? |
@Tarmil, not that I know much, trying with sharplab, with implicit interface implementation (but not related to IWSAM), the IL can avoid 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;}
} |
Was implemented |
@vzarytovskii will this also closes #668 ? |
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
The text was updated successfully, but these errors were encountered: