-
Notifications
You must be signed in to change notification settings - Fork 763
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
No compile-time error when static abstract member accessed on type parameter whose resolved type has no concrete implementation for said member #17139
Comments
I honestly don't think we can resolve it easily for general case, since it's a constrained runtime call by design, and it would be hard to distinguish such cases in compile time. We might though solve this specific one - for type functions, when type inferred is the interface. |
Yeah I agree, especially since presumably the mechanism that resolves
Unfortunately, the same thing happens when it's a regular function, too: #nowarn "3535"
type IFace =
static abstract P1 : int
type T =
interface IFace with
static member P1 = 1
let f<'T & #IFace> () = 'T.P1 + 'T.P1
f () // 'T is resolved to IFace. On the other hand, this problem probably shouldn't affect most uses of IWSAMs in the wild, since a type parameter constrained by a (recursively) generic IWSAM (like anything from open System.Numerics
let g<'T & #INumber<'T>> () = 'T.Zero + 'T.One
let _ = g ()
// error FS0071: Type constraint mismatch when applying the default type 'INumber<'a>'
// for a type inference variable. The types ''a' and 'INumber<'a>' cannot be unified.
// Consider adding further type constraints |
There is no compile-time error when:
A
System.Runtime.AmbiguousImplementationException
is raised at runtime instead. This is raised even when the interface in question has only one static abstract member (or member of any kind).Repro steps
net8.0
net9.0
Expected behavior
Resolution of the type variable should fail at compile-time in the absence of further type information when the type variable has a constraint involving static abstract members — although ideally it would only fail when an
abstract
(as opposed tovirtual
) member was actually being accessed, which is not visible through a constraint like'T & #IFace
alone.Actual behavior
A type variable like
'T & #IFace
resolves to the interface typeIFace
itself, and aSystem.Runtime.AmbiguousImplementationException
is raised at runtime.Known workarounds
Always manually ensure that all type variables are resolved to types with concrete implementations for all static abstract methods that are invoked on them.
Related information
.NET 8/9 preview.
This problem is similar in spirit to #14012, #16299, etc., although it might be a bit trickier to fix.
The text was updated successfully, but these errors were encountered: