This pull request only contains source updates from https://github.com/dotnet/runtime between commits fdecb6b73237947d1429b5d3de71edea536b5b53 and e302d2a27aef2196c8d710752da8b7726c5fe84d.

 /__w/1/s/src/fsharp/src/Compiler/Checking/NicePrint.fs(401,25): error FS0041: A unique overload for method 'TryParse' could not be determined based on type information prior to this program point. A type annotation may be needed.��Known types of arguments: string * NumberStyles * CultureInfo��Candidates:� - Int32.TryParse(s: ReadOnlySpan<char>, style: NumberStyles, provider: IFormatProvider | null, result: byref<int>) : bool� - Int32.TryParse(s: ReadOnlySpan<char>, style: NumberStyles, provider: IFormatProvider | null, result: byref<int>, charsConsumed: byref<int>) : bool� - Int32.TryParse(s: string | null, style: NumberStyles, provider: IFormatProvider | null, result: byref<int>) : bool� - Int32.TryParse(s: string | null, style: NumberStyles, provider: IFormatProvider | null, result: byref<int>, charsConsumed: byref<int>) : bool [/__w/1/s/src/fsharp/src/Compiler/FSharp.Compiler.Service.fsproj::TargetFramework=net11.0]

@T-Gro this likely needs reaction to dotnet/runtime#130210
FYI @tannergooding

Ah, that is an unfortunate break in the F# type inference (but understandably something that can occur with any new overload addition)

IIRC you can resolve like this if you want to keep the existing 3 line match syntax

-             match Int32.TryParse(rightMost, NumberStyles.Integer, CultureInfo.InvariantCulture) with 
+             match (Int32.TryParse(rightMost, NumberStyles.Integer, CultureInfo.InvariantCulture) : bool * int) with 
              | true, n -> n
              | false, _ -> 0 // looks like it's non-generic

and otherwise break it down to:

              let mutable n = 0
              match Int32.TryParse(rightMost, NumberStyles.Integer, CultureInfo.InvariantCulture, &n) with
              | true -> n
              | false -> 0

Yeah, it is why we are (from a type-inferred language perspective) often unhappy with any "lets use new overloads as our primary API design technique" in general.

I would be happy to change the compiler if there was any indication of the "main" (or OG) overload, but I cannot infer any rule for that unfortunately.

Given this doesn`t just break the FSharp compiler but all FSharp users, is there any chance to reconsider the placement of specialized features like this? Given this sits next to a very basic API? e.g. extension methods in a dedicated namespace come to mind.

Its not that we are against evolution - but here the "fix" objectively leads to worse F# code even for people not using those new APIs (similar for other scenarios from the past, where a "fix" lead to dropping type inference and annotating parameters).

I would be happy to change the compiler if there was any indication of the "main" (or OG) overload, but I cannot infer any rule for that unfortunately.

I'm not quite sure on this part.... There is a clear difference between:

match Int32.TryParse(rightMost, NumberStyles.Integer, CultureInfo.InvariantCulture) with 
| true, result -> result
| false, _ -> 0 // looks like it's non-generic

and

match Int32.TryParse(rightMost, NumberStyles.Integer, CultureInfo.InvariantCulture) with 
| true, result, consumed -> result
| false, _, _ -> 0 // looks like it's non-generic

That is, the former is explicitly a 2 item tuple and the latter a 3 item tuple. It is perhaps more surprising that the current syntax is allowed to be ambiguous at all, particularly given that it isn't otherwise legal code.

In other words, given the below and that T2 miscompiles because the number of tuple items mismatches, F# should have no issue disambiguating these in T3 since it can only match the 2 item tuple.

Given this doesn`t just break the FSharp compiler but all FSharp users, is there any chance to reconsider the placement of specialized features like this? Given this sits next to a very basic API? e.g. extension methods in a dedicated namespace come to mind.

It's not really specialized and is rather a core and highly requested feature that is common in other ecosystems and where the disconnected and limited UTF-8 version that lives in Utf8Parser is heavily used.

Is there any way we can annotate these today to get F# to do the "right" thing?

If F# truly has no way, then we'd probably need to have these new overloads explicitly implemented so they are still accessible via generic math (where T : INumberBase<T>), which should allow it to ship and still be accessible.

Then once F# gets a disambiguation in (either some attribute we can annotate these with or more ideally it just working since this should be unambiguous) we can get them exposed directly on the types

-- To be clear, I am already working on the change to avoid the F# break here for now, while still allowing the feature to ship. Should have it up shortly

Pushed up the commit that makes the relevant APIs explicitly implemented, which should resolve the F# break and still allow the functionality to be accessible via T.TryParse(...) given where T : INumberBase<T>

@tannergooding : Thank you greatly for making a patch for this 👍 .

For the long term mechanics:

Method resolution in F# cannot make assumptions based on later usage, as that might be type inferred as well.
let x = Int32.TryParse(rightMost, NumberStyles.Integer, CultureInfo.InvariantCulture)
Is x a pair or a triple here? No way to tell.

One way to indicate the "default" here would be OverloadResolutionPriorityAttribute (ORPA) which's support incl. multiple outs we could land in F# and it would be a general mechanism, not just a fix for this single scenario. It still relies on that attribute being applied that way in the runtime libraries👍 .

C# would not be affected, since with explicit hand-written out .. there is no conflict to resolve.
(the attribute is applied in language-specific scenarios already, e.g. its today's applications already assume compiler support for CallerArgumentExpression etc.)

Another option to resolve this particular occasion would be to describe the behavior via a dedicated method name instead of a flag and overloads.
From a "make illegal state unrepresentable" perspective it makes more sense - right now the usefulness of the overloads is tightly coupled to specific value of NumberStyles.

@akoeplinger, this looks ready to approve/merge