Fail to resolve to non generic overload.

[gusty]

The F# compiler fails to decide which overload to select, in this scenario and according to the spec it should prefer the non-generic method.

Not only fails to follow the F# spec, it also fails to apply the general .NET rule (not sure if it's written somewhere). The same in C# compiles fine and works as expected.

Repro steps

Try this code:

1. Step A

Send this to the F# interactive:

module Test =
    type C = 
        static member M<'T>(x:'T     ) = printfn "1"; x : 'T
        static member M<'T>(x:seq<'T>) = printfn "2"; x : seq<'T>

1. Step B

Now try this:

let x = Test.C.M(10)
let y = Test.C.M(seq [1..10])

Expected behavior

The expected behavior is to print 1, then 2 and return the input values.

If you compile Step A to a dll, reference it from C# and try:

var x = Test.C.M(10);
var y = Test.C.M(Enumerable.Range(1,10));

it compiles, print 1 and then 2 as expected.

Actual behavior

It fails to compile with the following error:

  let y = Test.C.M(seq [1..10]);;
  --------^^^^^^^^^^^^^^^^^^^^^
> 
stdin(4,9): error FS0041: A unique overload for method 'M' could not be determined based on type information prior to this program point. A type annotation may be needed. Candidates: static member Test.C.M : x:'T -> 'T, static member Test.C.M : x:seq<'T> -> seq<'T>

Known workarounds

No known workarounds.

Related information

• Operating system: All
• Branch : since the very first F# version up to the current master version.
• .NET Runtime, CoreCLR or Mono Version: N/A
• Editing Tools (e.g. Visual Studio Version): N/A
• Links to F# RFCs or entries on http://fslang.uservoice.com: N/A
• Links to performance testing scripts: N/A
• Indications of severity: Medium to High

[gusty]

I tried to fix this bug, came up with a quick fix but it breaks too many pieces of existing code, where the ambiguity was a feature.

[abelbraaksma]

(comment updated, made wrong assumptions earlier)

An interesting observation is that if you add annotations, it compiles fine and prints the correct output in FSI ("1", then "2"). Note that the annotations are identical, why it makes a difference I don't know, but it does give you a viable workaround.

module Test2 =
    type C = 
        static member M<'T>(x:'T     ) = printfn "1"; x : 'T
        static member M<'T>(x:seq<'T>) = printfn "2"; x : seq<'T>

    // added annotations
    let x = C.M<int>(10)
    let y = C.M<int>(seq [1..10])

The order of declaration does not seem to matter here (re: your original post). It may be related with this issue on the generic method resolution (and the order of choice precedence for overloads) changed between VS2012/2015, though in that case the actual order of declaration does matter.

I believe I read somewhere that there's a known limitation in F# with generic overloads, but if it is a limitation, a different error might be welcome, and at the least it shouldn't compile, not even my example above.

[gusty]

@abelbraaksma Thanks for you comment. Your workaround gives me a hint of what might be causing this problem.

[dsyme]

@gmpl I'm very glad you're investigating this issue. I'd love to see the issue addressed

Because this will almost certainly be a breaking change, I'm pretty sure we would have to take this through the http://github.com/fsharp/fslang-suggestions/RFC process. I'll tag this specific issue with By Design for now - though that's an indication of process not importance - I'd love to get to the bottom of this then work out what we do about it.

[gusty]

Thanks @dsyme

I agree that the solution to this bug might be a breaking change and if so we will have to go the RFC and discuss how to approach it.
But there is also a chance to find a solution that it's not a breaking change, for instance if something was not compiling and now it starts to compile that should be fine.

BTW I think these kind of bug's repro could be added to the tests.
You may wonder why, given that they're failing.
Well it happens from time to time that by solving problem X, unintentionally problem Y is also solved which is not a bad thing, on the contrary but it's good to know about it when it happens.

Actually it happened when solving #1530 that I had to correct an existing test which was printing twice a warning which logically should be printed only once.

[dsyme]

BTW I think these kind of bug's repro could be added to the tests. You may wonder why, given that they're failing. Well it happens from time to time that by solving problem X, unintentionally problem Y is also solved which is not a bad thing, on the contrary but it's good to know about it when it happens.

Is there a way to add such tests to NUnit test suites, e.g. an appropriate attribute to use?

Actually it happened when solving #1530 that I had to correct an existing test which was printing twice a warning which logically should be printed only once.

Yeah, I saw that, nice improvement :)

[gusty]

@dsyme
In that PR @forki added a failing test configured to fail with a specific error code. We can do the same with these repros.

[brianrourkeboll]

We have fsharp/fslang-suggestions#905 as a proposed way to fix this problem, but I do not see a canonical open issue here for it.

If there is not already some other open issue for it, we should either reopen this one or make a new one @T-Gro, since the problem still exists.

Here is another recent example from Slack involving Vector<T>.CopyTo, which has CopyTo(Span<Byte>), CopyTo(Span<T>), and CopyTo(T[]) overloads, and where the workaround from #1647 (comment) cannot be used:

open System
open System.Numerics

let someFunction () =
    let v: Vector<byte> = Vector(0uy)
    let array: byte[] = [||]
    let span: Span<byte> = Span(array)
    v.CopyTo(span)

    v.CopyTo(span)
----^^^^^^^^^^^^^^

stdin(8,5): error FS0041: A unique overload for method 'CopyTo' could not be determined based on type information prior to this program point. A type annotation may be needed.

Known type of argument: Span<byte>

Candidates:
 - Vector.CopyTo(destination: Span<byte>) : unit
 - Vector.CopyTo(destination: Span<byte>) : unit

I was able to come up with another workaround for that case using a type extension, but that kind of thing is probably very non-obvious to most people who might run into this:

open System
open System.Numerics

type Vector<'T> with
    member inline this.CopyToByteSpan (span : Span<byte>) = this.CopyTo span

let someFunction () =
    let v: Vector<byte> = Vector(0uy)
    let array: byte[] = [||]
    let span: Span<byte> = Span(array)
    v.CopyToByteSpan(span)

[T-Gro]

I can reopen this one.
The resolution remains the same - this needs an RFC which will cover the exact specifics as well as potential breaks caused by addressing this issue.

[T-Gro]

Related to it as well:
#14318
#16422