FS0193 when constraining a type parameter by different instanciations of the same interface

[SchlenkR]

Constraining a type parameter by different generic instanciations of the same interface results in an FS0193 error:

type IGet<'a> =
    abstract member GetValue : unit -> 'a

type T() =
    member this.DoIt<'a
        when 'a :> IGet<int>
        and  'a :> IGet<float> // FS0193: Type ''a' is not compatible with type 'IGet<float>'
        >
        (a: 'a) =
            let intValue = (a :> IGet<int>).GetValue()
            let floatValue = (a :> IGet<float>).GetValue()
            (float intValue) + floatValue

Expected behavior

Constraining in the provided way should be possible.

Actual behavior

Constraining results in an error: FS0193: Type ''a' is not compatible with type 'IGet<float>'

Known workarounds

// Not working (FS0193):
// ---------------------
// type IGetInt = IGet<int>
// type IGetFloat = IGet<float>

// Not working (FS0193):
// ---------------------
// type IGetInt =
//     interface
//         inherit IGet<int>
//     end
// type IGetFloat =
//     interface
//         inherit IGet<float>
//     end

// Disjoint types work:
// --------------------
type IGetInt =
    abstract member GetValue : unit -> int
type IGetFloat =
    abstract member GetValue : unit -> float

type T() =
    member this.DoIt<'a
        when 'a :> IGetInt
        and  'a :> IGetFloat
        >
        (a: 'a) =
            let intValue = (a :> IGetInt).GetValue()
            let floatValue = (a :> IGetFloat).GetValue()
            (float intValue) + floatValue

[michaeloyer]

I found that this kind of works with interfaces that implement two interfaces, but needs extra casting because once the compiler identifies that the generic variable 'context is of type IA<int>, it can no longer be of type IA<float>. Almost like the generic 'context isn't actually IABoth.

type IA<'a> =
    abstract member GetA: unit -> 'a

type IABoth =
    // If you flip these arround you'll get a compile error in IA<int> instead of IA<float>
    inherit IA<int>
    inherit IA<float>

type TestError() =
    member this.Get (c: 'context when 'context :> IABoth) : float =
        // Compile Error
        let m = (c :> IA<float>).GetA()
        let n = (c :> IA<int>).GetA() |> float

        n + m

type TestSuccess() =
    member this.Get (c: 'context when 'context :> IABoth) : float =
        // Works just fine, c appears to be #IABoth instead of IABoth
        let m = (c :> IABoth :> IA<float>).GetA()
        let n = (c :> IA<int>).GetA() |> float

        n + m

I hope this is simply a bug, but a part of me wonders if this will end up being an incompatibility with F#'s type system/type inference.

[KevinRansom]

@dsyme, this looks by design to me, what are your thoughts?

[dsyme]

Yes, this is by design, or can be turned into a language suggestion or linked to an existing one (short summary: there are limitations on generic constraints by multiple different interface instantiations, and lifting these limitations would make F# type inference less useful in practice)

[smoothdeveloper]

@dsyme, could you confirm about the part in the workaround from @michaeloyer:

(c :> IABoth :> IA<float>).

could this just work with direct safe cast to IA<float>? otherwise, I could see it may be leading to really interesting coding patterns, when dealing with frameworks having deep multi-inheritance hierarchies, just to reach members that remain hidden otherwise.

Would it require a change to the definition :> operator to support this or is it a type checker thing, and hence, potentially suffer from limitation around type inference?

Ideally, this part of the workaround should not be required, nor be a breaking change to get there, is it too hopeful?