-
Notifications
You must be signed in to change notification settings - Fork 794
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
F# compiler still treats FSharpFunc as sealed in generic constraints #9692
Comments
@dsyme will need to look at it.
I'm not sure what problem you are trying to solve. What problem requires this type of pattern? |
To note: AFAIK, de-virtualization will only happen if the concrete implementation is a struct, it does not do it for reference types. |
Mostly I was experimenting. It's to get the JIT to devirt and then inline a whole bunch of boilerplate virtual calls (lenses that must be function values in this case). Devirtualization happens when the concrete type is known, say a visible newobj or generic specialization of a method that has a bound and is a sealed class. Generic specialization happens if there is at least one value type involved in the generic method call. Most likely though, bounding this example to something like: [<Struct>]
type FuncBox<'t, 'u,'v when 't :> FSharpFunc<'u,'v>> = FuncBox of 't
interface IFuncBox<'u,'v> would be my obvious choice, however, the constraint still wouldn't be accepted by the compiler today. |
// cc @AndyAyersMS |
@TIHan any question for Andy (or me?) |
I'll treat this as a spec/design issue rather than saying this was ever intended to work as things stand today
This means the unsealed nature of the representation is lost to the F# programmer. |
Closing, please open a language suggestion if you'd like to. |
I've recorded this in the list of issues where precise language spec clarifications are needed: fsharp/fsharp.org#841 |
And a sharplab link
https://sharplab.io/#v2:DYLgZgzgNAJiDUAfA9gBwKYDsAEBlAnhAC7oC2AsAFBH4bYDCAFAJTYC8V2X2pZARugBO2APoA6ALIAeAORgo2GQEMFMvtgDuACyyKw2EAD5sAMVxalg1CYCumAMayVivocOMwIPazbYWQA=
The idea behind using a constraint like this is to strongly box an FSharpFunc inside a struct so it can be devirtualized and potentially inlined as a result – as
'f
is now a known sealed implementation for the JIT.Partial fix mentioned in:
#3737
The text was updated successfully, but these errors were encountered: