Type is not inferred automatically in CE function .Yield parameter when other overloads are present

[Lanayx]

I'm building a library that heavily depends on .Yield overloads in CE. I've found the case when it is expected for the type to get inferred automatically, however it is not

Repro steps

open System

type Test() =
    member inline _.Yield(value: int -> unit) = ignore
    member inline _.Yield(value: string) = ignore // without this overload issue is not observed
    member inline _.Zero() = ignore

let x =
    Test() {
        yield (fun y -> Console.WriteLine(y))
    }

Expected behavior

I expect the code above to compile since the y type should be inferred to int.

Actual behavior

Compilation error, since y requires specifying type explicitly.

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

Known type of argument: 'a

Candidates:
 - Console.WriteLine(buffer: char array) : unit
 - Console.WriteLine(format: string, [<ParamArray>] arg: obj array) : unit
 - Console.WriteLine(value: bool) : unit
 - Console.WriteLine(value: char) : unit
 - Console.WriteLine(value: decimal) : unit
 - Console.WriteLine(value: float) : unit
 - Console.WriteLine(value: float32) : unit
 - Console.WriteLine(value: int) : unit
 - Console.WriteLine(value: int64) : unit
 - Console.WriteLine(value: obj) : unit
 - Console.WriteLine(value: string) : unit
 - Console.WriteLine(value: uint32) : unit
 - Console.WriteLine(value: uint64) : unit

Known workarounds

Specify y type explicitly

Related information

.NET SDK:
 Version:           9.0.100-rc.1.24452.12
 Commit:            81a714c6d3
 Workload version:  9.0.100-manifests.67cd1eb6
 MSBuild version:   17.12.0-preview-24422-09+d17ec720d

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22631
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.100-rc.1.24452.12\

[vzarytovskii]

Does it show overloads in the message?

[vzarytovskii]

Does it show overloads in the message?

Just checked, it just checks all candidates, which probably means it's in the generic code or something.

Update: yeah, it's due to both yields and continuations are generic and at the call for writeline, type is not known. Not sure how we will get around it

Cc @T-Gro

[Lanayx]

Right, updated the description with full error message

[T-Gro]

I believe this is not a regression, but haven't checked with (even) older versions.

https://sharplab.io/#v2:DYLgZgzgNALiCWwA+B7ADgUwHYAIDKAnhDBgLYCwAUFTAZjgCobEAUAlDgLxU686lkARhgBOOeFmASMOAPoA6AJrwMwACYsAbgENgAVwwhxWGDgC0APhx6s8GB07iA5lhQiMPPgNLCxEqVgyCsqqGjr6hjjEIhJODs6u7jgA9Mk4AO52ABYoeqYwWfAQOCiaosAo2mriEBAGNTiupiiCEKJlap683r7GAUHyAFqiKOxcCW4e1JTAGKYAHlxdjMwwYwDey3w4BCrqOCxgNjvmVgDCKFgQKLPyAOoxJAAy0iwEbGzLAL5AA===

[T-Gro]

(btw. I formatted the error message in the issue description to make it more readable and apparent about the overloads)

[vzarytovskii]

It's not a regression, no. It's caused by the fact that generics are involved and type is not known by the time WriteLine is called.

[T-Gro]

I do not think its by generics. If I replace all the ignore (which is what puts in genericity) with (), I still get the same issue.

It is a consequence of the order of type inference.
Adding type annotation to y fixes it - https://sharplab.io/#v2:DYLgZgzgPg9gDgUwHYAIDKBPCAXBBbAWAChjsNEUAVBHACgEoUBeYlNlPfAIwQCcUAlkmBCEKAPoA6AJoCEwACa0AbgENgAVwQhBSbCgC0APhQakA7IyYoGrdpzw9+QkUjFTZ8pWs3aUOXiEAcysbRgB6cJQAdwsACxgNfWw4gQgUGGU+YBhVBUEICC0ClCQYfRguCD4shTs2ByddV3dJAC0+GAZmMOJiYAR9AA9meqoabG6AbzH2FAw5RRswMxsMECFLQxMAYRgkCBgByQB1QNwAGVFaDHp6MYBfIA= .

In the general case, I believe this is a method resolution feature proposal for:

• The callsite is known to be passing in a function (not yet fully resolved, but known to be a function)
• There is exactly one overload with a function type argument

[vzarytovskii]

I do not think its by generics. If I replace all the ignore (which is what puts in genericity) with (), I still get the same issue.

It is a consequence of the order of type inference. Adding type annotation to y fixes it - sharplab.io#v2:DYLgZgzgPg9gDgUwHYAIDKBPCAXBBbAWAChjsNEUAVBHACgEoUBeYlNlPfAIwQCcUAlkmBCEKAPoA6AJoCEwACa0AbgENgAVwQhBSbCgC0APhQakA7IyYoGrdpzw9+QkUjFTZ8pWs3aUOXiEAcysbRgB6cJQAdwsACxgNfWw4gQgUGGU+YBhVBUEICC0ClCQYfRguCD4shTs2ByddV3dJAC0+GAZmMOJiYAR9AA9meqoabG6AbzH2FAw5RRswMxsMECFLQxMAYRgkCBgByQB1QNwAGVFaDHp6MYBfIA= .

In the general case, I believe this is a method resolution feature proposal for:

• The callsite is known to be passing in a function (not yet fully resolved, but known to be a function)
• There is exactly one overload with a function type argument

That's what I meant, it's the same issue as https://sharplab.io/#v2:DYLgZgzgPsCmAuACMA7RBeZBXNBPRAtAHyIDKuE8sAtgHQDCA9ihI3LQOoBOAllQDI8UsABS4AlAFgAUEA==, but in case of CE, we can't derive type of function parameter from overload of yield, and it's just 'a here (which is not generic, but unresolved, yes). Not yet sure how can we changed it.