"Duplicate method ... same signature" error occurs for member names other than op_Implicit

[cmeeren]

Consider this code:

type A =
  | A of int
  static member M(A x) : int = x
  static member M(A x) : string = x.ToString()

This leads to the following compilation error:

Duplicate method. The method 'M' has the same name and signature as another method in type 'A'.

I assume "signature" refers to the parameters and ignores the return type. However, using the name op_Implicit works fine:

type A =
  | A of int
  static member op_Implicit(A x) : int = x
  static member op_Implicit(A x) : string = x.ToString()

Why should it depend on the name? Is this a bug?

My use-case is that I am using some SRTP helpers to convert between compatible types, but I'd like to move away from relying on op_Implicit for these helpers in order to force myself to use these helpers. With op_Implicit, I get automatic conversion at method call sites (but I don't want to enable the warning/error for this, since I want that implicit conversion for some built-in .NET APIs/types).

Related information

• Windows 11
• Rider 2022.2.3

[vzarytovskii]

I do believe it's by design that we don't take return type into account when resolving overloads, more details here:
fsharp/fslang-suggestions#820

Regarding implicit conversions, I think, it may be a result of https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0/FS-1093-additional-conversions.md

@dsyme fyi

[cmeeren]

Regarding implicit conversions, I think, it may be a result of https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0/FS-1093-additional-conversions.md

I used op_Implicit like this before #10884 was merged.

[vzarytovskii]

Regarding implicit conversions, I think, it may be a result of https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0/FS-1093-additional-conversions.md

I used op_Implicit like this before #10884 was merged.

Then it is likely just a special case for it (need to look into spec).

[dsyme]

This is by design - overloading by return type is only allowed for op_Implicit and op_Explicit, it's simply not allowed for other members.

Return types are only taken into account on SRTP constraint solving.

op_Implicit/Explicit are just so different to other members as they nearly only ever invoked through this constraint solving or other F# 6 implicit conversion resolution. Plus you simply can't define useful sets of these overloads without overloading by return type.

For other methods, we ban overloading by return type because it would give the false impression that return types are taken into account bin overload resolution.

I agree there's a corner case migration problem here making it hard to migrate away from op_Implicit. I guess some attribute to allow overloading by return type could make sense. I have a feeling that's been proposed before, need to search for it.

Anyway, currently by design and would need to go via a language suggestion

[cmeeren]

Thanks! I thought about using op_Explicit instead (seems like it would fit better semantics-wise since I am using a custom operator to do the conversion, thereby making it explicit). But this comes with a warning FS0077:

[FS0077] Member constraints with the name 'op_Explicit' are given special status by the F# compiler as certain .NET types are implicitly augmented with this member. This may result in runtime failures if you attempt to invoke the member constraint from your own code.

Cursory testing seems like it would work for my codebase. Web searches for this error code gives few results. Anything I should watch out for?

If it's relevant, I'm using

let inline (!) (x: ^a) : ^b =
  ((^a or ^b): (static member op_Explicit: ^a -> ^b) x)

and then using myFun !param to convert between the type of param1 and the type myFun expects. This is usually used to convert single-case DU wrappers to primitive types on the "edges" of the application (e.g. in calls to DB code).

[NinoFloris]

I have a feeling that's been proposed before, need to search for it.

You're correct, it lives in the trait extension PR #6805 as AllowOverloadOnReturnTypeAttribute. Which would close the proposal fsharp/fslang-suggestions#820