Overload resolution for Result cannot be determined when a method for Nullable exists

[pedersorensen]

If a type has a method with overloads for both Nullable<T> and Result<T, TError>, the overload for Result cannot be resolved by the compiler.

Repro steps

1. Create a type like the following (method bodies are not important, only the signatures)

type M() =
    static member A(n: Nullable<'T>) = ()
    static member A(o: Option<'T>) = ()
    static member A(r: Result<'T, 'TError>) = ()

2. Call the various overloads:

M.A(Some 3)
M.A(Nullable 3)
M.A(Ok 3) // <-- Does not compile
M.A(Result<int, string>.Ok 3) // <-- Nor when the type of Result is fully specified

The last two lines yield the following compiler error

error FS0041: A unique overload for method 'A' could not be determined based on type information prior to this program point. A type annotation may be needed.

Known type of argument: Result<int,string>

Candidates:
 - static member M.A: n: Nullable<'d> -> bool when 'd: (new: unit -> 'd) and 'd: struct and 'd :> ValueType
 - static member M.A: r: Result<'a,'b> -> bool

The same behavior occurs for instance methods with a similar setup.

Expected behavior

All three methods should be callable.

Actual behavior

Calling the overload that takes a Result<T, TError> does not compile.

Known workarounds

1. Use /langversion:4.7

2. Using a named parameter resolves the correct overload, provided the names of the parameters of the different overloads are different:

   let c1 = M.A(r = Ok 3)

   If the Nullable<T> overload is removed, the Result<T, TError> overload can be called just fine.

Related information

• OS: Windows 11
• .NET Runtime kind .NET 6
• Visual Studio version 17.1.1
• F# version 6.0

[dsyme]

At a first glance it does look like a bug - method overloads that use type-directed-conversion to Nullable should not be preferred over ones that don't. I'll look deeper

[dsyme]

Note this does compile with 4.7, so I'll mark this as a regression. My initial understanding is the preference rule was applied to TDCs in general, but not to the specific Nullable conversion added in 5.0

[dsyme]

Fix to this issue is in the works #13063