op_Implicit not resolved when having a generic type called via a static member

[MangelMaxime]

Hello,

I am working with op_Implicit in order to make a Fable binding. Doing so allows for a nice syntax while still being able to represents the crazy API coming from JavaScript (which we all love 😅).

However, there are situation where it seems like the op_Implicit is not resolved and requires the creation of an intermediate variable.

type Record =
    {
        x : int
    }

type ErasedType =
    | Case1 of int
    | Case2 of ResizeArray<string>
    | Case3 of {| x : int |}
    | Case4 of Record
    | Case5 of string list

    static member op_Implicit(v: int) = Case1 v
    static member op_Implicit(v: ResizeArray<string>) = Case2 v
    static member op_Implicit(v: {| x : int |}) = Case3 v
    static member op_Implicit(v: Record) = Case4 v
    static member op_Implicit(v: string list) = Case5 v

type Prop =
    static member inline prop1(v: ErasedType) =
        failwith "Not implemented"

let variable = ResizeArray ["a"; "b"; "c"]

Prop.prop1 2 // Works when value is inlined
Prop.prop1 variable // Works when using an intermediate variable
Prop.prop1 {| x = 2 |} // Works
Prop.prop1 { x = 2 } // Works
Prop.prop1 [ "a"; "b"; "c" ] // Does not work
Prop.prop1 (ResizeArray ["a"; "b"; "c"]) // Does not work when defining the ResizeArray directly
ResizeArray ["a"; "b"; "c"] |> Prop.prop1 // Works
Prop.prop1 (ResizeArray ["a"; "b"; "c"] : ErasedType) // Works with a warning about implicit conversion

Something that I find strange also the following:

Prop.prop1 (ResizeArray ["a"; "b"; "c"]) // Does not work
ResizeArray ["a"; "b"; "c"] |> Prop.prop1 // Works

In my mind they are equivalent so my supposition is F# compiler type inference is not resolved the same way in this situation?

Even if we try to help the type system as much as possible, by fully qualifying the ResizeArray it does not seems to be enought:

Prop.prop1 (ResizeArray<string> ["a"; "b"; "c"]) // Does not work

My goal with this discussion is to check if this is expected or if this is something that could perhaps be improved?

Edit:

We discovered that using seq { .. } instead of the list builder works:

Prop.prop1 (ResizeArray<string> (seq {"a"; "b"; "c"}))

[brianrourkeboll]

Hmm, I've definitely seen overload resolution ambiguities arise before when there are overloads with generic types, even when a type argument is supplied, e.g., #14318, and even when the method being overloaded is not op_Implicit.

...But these all work fine:

// These all work.
ErasedType.op_Implicit 2
ErasedType.op_Implicit variable
ErasedType.op_Implicit {| x = 2 |}
ErasedType.op_Implicit { x = 2 }
ErasedType.op_Implicit [ "a"; "b"; "c" ]
ErasedType.op_Implicit (ResizeArray ["a"; "b"; "c"])
ResizeArray ["a"; "b"; "c"] |> ErasedType.op_Implicit
ErasedType.op_Implicit (ResizeArray ["a"; "b"; "c"])

[MangelMaxime]

Yes these works but in my case, the op_Implicit resolution is not called directly by me but is handled automatically by the F# compiler when resolving Prop. prop1 call and that's where it fails for the ResizeArray ["a"; "b"; "c"] case at least when provided in as Prop.prop1 (ResizeArray ["a"; "b"; "c"]).

I would expect it to work just like other cases unless this is one of the limitation documented in the RFC but I could not find a confirmation of that from what I understood from it.

[brianrourkeboll]

Yeah, I agree. I just meant to show that there was not an inherent problem with overload ambiguity in this case (since I thought that might have been a possibility). But the rules for type-directed conversions are even more complicated than regular overload resolution, so my guess is that the problem has something to do with that: compare #14302 and, e.g., #14319 (comment).