Create FS-1129-shorthand-anonymous-unary-functions

[tboby]

This is just a starting point for https://github.com/fsharp/fslang-suggestions/issues/506 with a basic proof of concept implementation found at https://github.com/dotnet/fsharp/pull/13907

[kerams]

Is intra-assembly closure reuse feasible?

let r1: Record = ...
let r2: Record = ...
let r1x = r1 |> Option.map _.x
let r2x = r2 |> Option.map _.x

There should ideally be only one generated closure per property on type in an assembly, and it could be given a descriptive name.

[vzarytovskii]

Is intra-assembly closure reuse feasible?

let r1: Record = ...
let r2: Record = ...
let r1x = r1 |> Option.map _.x
let r2x = r2 |> Option.map _.x

There should ideally be only one generated closure per property on type in an assembly, and it could be given a descriptive name.

Behaviour should be no different to how full lambda works now, since we just rewrite _.Prop to regular lambda in untyped ast.

[T-Gro]

But even the full lambda as of now produces duplicates for identical operations. https://sharplab.io/#v2:DYLgZgzgPg9gDgUwHYAIDKBPCAXBBbAWAChjjgFsUAnARgA9qaUBeRlKAPhQHk5sBLGEgB0eAIZwUACjABXVAwC0XOsIAqMNNir8kAcykBKQ2QrUATAyrmWF9l14ChoidLkKUylKo1ad+o0MgA==

I believe the comment from @kerams is valid && orthogonal => might be worth a separate suggestions for the optimizer to de-duplicate identical lambda-generated classes.

[vzarytovskii]

But even the full lambda as of now produces duplicates for identical operations. https://sharplab.io/#v2:DYLgZgzgPg9gDgUwHYAIDKBPCAXBBbAWAChjjgFsUAnARgA9qaUBeRlKAPhQHk5sBLGEgB0eAIZwUACjABXVAwC0XOsIAqMNNir8kAcykBKQ2QrUATAyrmWF9l14ChoidLkKUylKo1ad+o0MgA==

I believe the comment from @kerams is valid && orthogonal => might be worth a separate suggestions for the optimizer to de-duplicate identical lambda-generated classes.

I honestly think we shouldn't be doing such analysis, since it can be quite complex with little benefits.

[smoothdeveloper]

The feature is going to be shipping but it is very difficult to get access to the RFC as it wasn't merged and the suggestion description doesn't mention it. Also no discussion thread was opened for the RFC itself.

I'm mostly concerned seeing the feature implementation is not restricted to properties only (which was Don main restraint for initial take on the feature) and will have a few rough edges on release in terms of tooling (which the F# users should be ok with, as things will be sorted out); but overall, we should make sure the suggestion discussion is closed in favor to a discussion related to the RFC, and that the RFC (even if not the last one) is visible in the repository itself, with the link to the discussion thread.

I'd prefer an almost empty RFC in the repository, with link to the discussion thread, and the suggestion being closed (with top post updated with links, as well as the closing comment), than the current situation.

(edit: and to be clear, I think users are going to love this feature, it is great feature that will have big impact on the codebases)