Support explicit struct optional args (?x=…)

[brianrourkeboll]

Description

Fixes #19074.

• Support explicit struct optional args: ?x=….

Checklist

• Test cases added.
• Release notes entry updated.

[github-actions]

❗ Release notes required

@brianrourkeboll,

Caution

No release notes found for the changed paths (see table below).

Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format.

The following format is recommended for this repository:

* <Informative description>. ([PR #XXXXX](https://github.com/dotnet/fsharp/pull/XXXXX))

See examples in the files, listed in the table below or in th full documentation at https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

You can open this PR in browser to add release notes: open in github.dev

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/10.0.200.md	No release notes found or release notes format is not correct

[brianrourkeboll]

This is a bit of hack and might cause other problems.

I wonder if it could/should be done here instead?

fsharp/src/Compiler/Checking/Expressions/CheckExpressions.fs

Line 9945 in cfda5f6

and TcMethodApplication_UniqueOverloadInference

fsharp/src/Compiler/Checking/Expressions/CheckExpressions.fs

Lines 9966 to 9968 in cfda5f6

	// Build the CallerArg values for the caller's arguments.
	// Fake up some arguments if this is the use of a method as a first class function
	let unnamedCurriedCallerArgs, namedCurriedCallerArgs, returnTy =

[brianrourkeboll]

...Lol, yeah, it broke a bunch of stuff.

[brianrourkeboll]

Meh. Won't work there, either.

We'd really need to somehow defer checking the kind of the optional param till overload resolution...

[brianrourkeboll]

Oh, silly. I forgot to check whether the caller arg was an explicit optional arg here:

fsharp/src/Compiler/Checking/ConstraintSolver.fs

Lines 3216 to 3219 in 669a6bb

	let callerTy =
	let g = csenv.g
	if isValueOptionTy g calledArgTy && isOptionTy g callerTy then mkValueOptionTy g (destOptionTy g callerTy)
	else callerTy

But even if I did check that, this approach seems potentially wrong: is it possible to know here that a different overload wouldn't be picked if we didn't swap out the caller arg type? Would doing some subset of the overload resolution analysis here be enough, e.g., at least making sure that the explicit optional caller arg's position lined up with at least one struct optional arg's position on a candidate method?