function implicit conversion the same way as fun x

[edgarfgp]

Description

Fixes #7401

Checklist

• Test cases added
• Release notes entry updated

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/9.0.100.md

[psfinaki]

Nice, thank you Edgar!

[psfinaki]

/azp run

[brianrourkeboll]

Two comments on the approach used in 581be73:

1. I think that it follows the spirit of the existing code in that it simply looks at available syntactic information.
2. If we are worried about additional heap allocations (tuples, continuations), we can likely reduce them, perhaps at the expense of some code complexity.

[vzarytovskii]

Two comments on the approach used in 581be73:

1. I think that it follows the spirit of the existing code in that it simply looks at available syntactic information.

2. If we are worried about additional heap allocations (tuples, continuations), we can likely reduce them, perhaps at the expense of some code complexity.

Can we measure the diff between old and new allocation-wise in long-running scenarios?

One-off compilation won't be a concern, continuous allocations in tooling might be. Service currently is not exactly known to be memory-friendly, probably don't want make it worse (I doubt it will be with the change, since nothing will likely escape gen0, but just want a sanity check).

[brianrourkeboll]

@vzarytovskii

1. If we use struct tuples, then I think there should be no additional allocations in the common case (method calls taking anything other than lambdas, address-of, or quotes).
2. Even for method calls taking lambdas, the additional allocations should effectively be equal to the number of curried arguments in the lambda sequence, i.e., one continuation closure each, as in cont = new loopExpr@24-2<a, b>(cont);.

[edgarfgp]

@vzarytovskii

1. If we use struct tuples, then I think there should be no additional allocations in the common case (method calls taking anything other than lambdas, address-of, or quotes).
2. Even for method calls taking lambdas, the additional allocations should effectively be equal to the number of curried arguments in the lambda sequence, i.e., one continuation closure each, as in cont = new loopExpr@24-2<a, b>(cont);.

@vzarytovskii Does Brian's changes cover your expectations ?