cc @brettfo @KevinRansom

@TIHan

snip:

When compiling with .NET Core, these functions call methods with Span overloads, creating an ambiguity.

probably you can take a look at this.

So I think the issue is that:

1. This script was using the curried form for method calls
2. These methods now have an additional overload on .NET Core

Both combined caused the ambiguity and thus the compile error. Explicitly calling it as a method and specifying string fixes it.

@cartermp, Sweet, send a PR, nice work.

This is the PR 😄

Lol … I thought it was an issue … clearly when working at home, I should focus more.

@cartermp why did span cause ambiguity for these APIs? I don't understand why there was a failure.

Just standard pains with type inference + method overloads + F#-style parameter passing to .NET methods.

Prior to the .NET Core 2.1 builds, it was effectively like doing this:

type C() =
    static member Foo(str: string) = ()

let f1 x = C.Foo x

But now it's effectively like this:

type C() =
    static member Foo(str: string) = ()
    static member Foo(i : int) = ()

let f1 x = C.Foo x

Which produces:

A unique overload for method 'Foo' could not be determined based on type information prior to this program point. A type annotation may be needed. Candidates: static member C.Foo : i:int -> unit, static member C.Foo : str:string -> unit

And that was the cause of the build failure. Why the build only started using these updated APIs is unknown to me, but the fix is to just call the methods as methods.

What's perhaps interesting is that the type annotation alone did not fix it; I needed to pass it in with parentheses rather than as if it were F#-style function application.

can you please merge asap to get master green?