0

Given the type

type T = 
    static member OverloadedMethod(p:int) = ()
    static member OverloadedMethod(p:string) = ()

Let's suppose we want to create a generic function that resolves to the specific overload based on the type of the parameter. The most intuitive way would be

//Case 1

let inline call o = T.OverloadedMethod o //error

call 3
call "3"

but this, despite the inline definition, doesn't work and the compiler complains

Error FS0041 A unique overload for method 'OverloadedMethod' could not be determined based on type information prior to this program point. A type annotation may be needed. Candidates: static member T.OverloadedMethod : p:int -> unit, static member T.OverloadedMethod : p:string -> unit

We can achieve what we want though, for example using the "operator trick"

//Case 2

type T2 =

    static member ($) (_:T2, p:int) = T.OverloadedMethod(p)
    static member ($) (_:T2, p:string) = T.OverloadedMethod(p)

let inline call2 o = Unchecked.defaultof<T2> $ o

call2 3
call2 "3"

The F# compiler here does (apparently) some more work and doesn't simply fall back to the .NET resolution.

Yet, this looks ugly and implies code duplication. It sounds like Case 1 should be possible.

What technical reasons justify this behaviour? My guess is that there is some trade-off (perhaps with .NET interoperability), but couldn't find more information.

EDIT

From the posts I extract this as a reason:

"a trait call is an F# compiler feature, so there must be two different ways of writing a simple call and a trait call. Using the same syntax for both is not convenient because it might be confusing, some uses could arise where a simple call is compiled as a trait call accidentally".

Let's put the question in a different perspective:

Looking at the code, it really seems straightforward what the compiler should do:

1) call is an inline function, so defer compilation to the use site

2) call 3 is an use site, where the parameter is of type int. But T.OverloadedMethod(int) exists, so let's generate a call to it

3) call "3" like previous case with string in place of int

4) call 3.0 error as T.OverloadedMethod(float) doesn't exist

I would really like to see a code example where letting the compiler do this would be a problem that justifies requiring the developer to write the additional code for the trait call.

At the end of the day, isn't one of F# strengths "conciseness and intuitiveness"?

Here we are in presence of a case where it looks like it could be better.

Franco Tiveron
  • 2,364
  • 18
  • 34

2 Answers2

1

The trade-offs stem from the fact that this it's a completely erased compiler trick. This means that:

  1. C# code can't see (and take advantage of) any call2 function, it can only see your two $ method overloads.
  2. All information about call2 is gone at runtime, meaning you couldn't invoke it through reflection, for example.
  3. It won't show up in call stacks. This may be a good or a bad thing -- for example, in recent versions of the F# compiler, they've selectively inlined certain functions to make async stacktraces a bit nicer.
  4. The F# is baked in at the call site. If your calling code in is assembly A call2 comes from assembly B, you can't just replace assembly B with a new version of call2; you have to recompile A against the new assembly. This could potentially be a backwards compatibility concern.

A rather interesting benefit is that it can lead to drastic performance improvements in specialized cases: Why is this F# code so slow?. On the flip side, I'm sure there are circumstances where it could cause active harm, or just bloat the resulting IL code.

Jwosty
  • 3,497
  • 2
  • 22
  • 50
  • Wouldn't it be possible to compile call 3 and call "3" into erased calls to T.OverloadedMethod(int) and T.OverloadedMethod(string), respectively? – Franco Tiveron Aug 16 '18 at 04:31
  • @FrancoTiveron Correct, that's exactly what's going on in your code snippet. – Jwosty Aug 16 '18 at 04:32
  • ? in my code snippet call 3 and call "3" are not compiled due to the error in call's definition; call2 3 and call2 "3" are compiled – Franco Tiveron Aug 16 '18 at 04:36
  • @FrancoTiveron Oh, sorry, I misread that as `call2`, that was wrong information. Your first snippet doesn't compile because it doesn't have STRP (statically resolved type parameters -- the generics with a hat symbol, as in `^T` as opposed to `'T`). Operators are special because they implicitly give you STRPs; otherwise, you have to write them manually. See: https://stackoverflow.com/questions/37607979/how-does-non-idiomatic-global-operator-overloading-work?rq=1 – Jwosty Aug 16 '18 at 05:11
  • if you mean defining call as in "let inline call (o: ^a) = T.OverloadedMethod o" then this doesn't fix the error – Franco Tiveron Aug 16 '18 at 05:56
1

The reason of that behavior is that T.OverloadedMethod o in

let inline call o = T.OverloadedMethod o

is not a trait call. It's rather simple .NET overloading that must be solved at the call site, but since your function type doesn't imply which overload to solve it simply fails to compile, this functionality is desired.

If you want to "defer" the overload resolution you need to do a trait call, making the function inline is necessary but not sufficient:

let inline call (x:'U) : unit =
    let inline call (_: ^T, x: ^I) = ((^T or ^I) : (static member OverloadedMethod: _ -> _) x)
    call (Unchecked.defaultof<T>, x)

Using an operator saves you many keystrokes by inferring automatically these constraints but as you can see in your question, it requires to include a dummy parameter in the overloads.

Gus
  • 25,839
  • 2
  • 51
  • 76
  • I am aware of the ways to achieve the result (explicit constraints or implicit by indicators). However, I am trying to go a little further and would like to understand why this is really necessary. Looking at the code it seems quite easy to understand what the "call" function wants, so it comes natural to think that the compiler should be able... – Franco Tiveron Aug 16 '18 at 07:20
  • ...to understand what the intentions are, without requiring a trait call or other forms of "explanations". As such one is brought to think that there must be some other reasons that make convenient or necessary the trait definition. I would like to understand these reasons, is possible. – Franco Tiveron Aug 16 '18 at 07:20
  • Sorry, I thought I already explained the reasons. I can add that a trait call is an F# compiler feature, so there must be two different ways of writing a simple call and a trait call. Using the same syntax for both is not convenient because it might be confusing, some uses could arise where a simple call is compiled as a trait call accidentally. – Gus Aug 16 '18 at 12:43