Members that take a flexible type cannot be overloaded

[abelbraaksma]

Whether or not two type hierarchies overlap doesn't seem to matter, whenever I try to create an overload of a class member that both have a flexible type annotation, I get the error:

error FS0438: Duplicate method. The method 'Get' has the same name and signature as another method in type 'TestEager.Flex'.

Repro steps

I encountered this in a real-world scenario with #seq<Foo> and #exn, but it appears to happen with any type, so here's a minimal example:

type Flex() =
    static member Get(d: #Uri) = 42                 // FS0438
    static member Get(d: #System.IO.Stream) = 52    // FS0438

Expected behavior

There's no overlap in the type hierarchies, so the error should not be thrown. But if, for some reason, this is not supported (there's no mention of it in the docs, and I couldn't find it when googling, but please correct me if I'm wrong), a variant of the error, something like "Two overloads with a flexible type are not supported" or something, would certainly be more helpful.

Actual behavior

As observed above: an error is thrown, but (I think) it shouldn't.

Known workarounds

Write out an overload of each known implementation of the interface or class you want to represent. In my real world scenario, for sequences and exceptions, this is obviously not possible, so the other workaround is to use different names for the members (and yes, I know it sounds odd, but I actually do have a case were these two overloads, #exn and #seq<_>, make sense).

Related information

Seen and tested on F# 4.0 and 4.1, in VS2017 (almost) most recent Preview as of today: 15.7 Preview 6.

[vasily-kirichenko]

C# does not allow this kind of overloading either:

https://sharplab.io/#v2:D4WAUAAgzABBBMMDCMDe4abrCAWGAsgBQCUaGWAvhZjTAJYB2ALgKYBOAZgIYDGrMAJIE01MFgYsOPfkIByounSbNCAHgAqAPiIaGZAO4ALDgI0AuISIC8WmAEYA3EvFZlLddt36Yx0zAt5GFsHZzBKIA===

[dsyme]

That's correct, the constraints aren't part of the MethodRef identity on the caller side

[abelbraaksma]

It's a bit surprising, but thinking it through I understand that it's not possible to predict whether a class is created that implements both the interface and the class, in which case the error makes sense, I guess.

[abelbraaksma]

Ran into this again today. If there's no overlap and the flex types are not interfaces, I don't see how resolution should be impossible.

Wonder if this is a CLR/IL restriction.