[RFC FS-1115] Tracking the use of InlineIfLambda in FSharp.Core

[kerams]

Discussion for https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1115-InlineIfLambda-in-FSharp-Core.md

There are no known drawbacks of using this with the above functions

• What would be an example of a drawback? Does a lambda get inlined even when it's used multiple times, increasing assembly size?
• Does there have to be a clear benefit to inlining with every function, i.e. we don't want to sprinkle the attribute everywhere willy-nilly?

Of note: dotnet/fsharp#12388

[kerams]

The Option module and its functions immediately comes to mind as a candidate.

[TheAngryByrd]

Option module, Value Option, Result module all would be easy candidates for me.

[kerams]

Indeed, those functions are so small that they could at least be inlined (a few already are).

[TheAngryByrd]

If anyone wants to see my exploration with Benchmarks and SharpLab output for inlining some of these functions: demystifyfp/FsToolkit.ErrorHandling#166

[vzarytovskii]

One drawback which comes to mind is compilation/codegen speed, it may slow it down significantly is some cases.

[kerams]

Codegen should be offset by the fact that closures no longer need to be emitted?

[dsyme]

What would be an example of a drawback? Does a lambda get inlined even when it's used multiple times, increasing assembly size?

Yes, the RFC assumes single-use functions

[dsyme]

Does there have to be a clear benefit to inlining with every function, i.e. we don't want to sprinkle the attribute everywhere willy-nilly?

Hard to tell. I don't know of any specific downsides though.

[dsyme]

Option module, Value Option, Result module all would be easy candidates for me.

Yes, all these should have it.