Spread operator { ...expr }, { ...ty } for records

[brianrourkeboll]

Description

Add support for the spread operator ... in record types and expressions (nominal and anonymous).

type R1      = { A : int; B : int }
type R2      = { C : int; D : int }
type R3      = { ...R1; ...R2; E : int } // { A : int; B : int; C : int; D : int; E : int }

let r1       = { A = 1; B = 2 }
let r2       = { C = 3; D = 4 }
let r3       = { ...r1; ...r2; E = 5 }   // { A = 1; B = 2; C = 3; D = 4; E = 5 }

let r1' : R1 = { ...r3; B = 99 }         // { A = 1; B = 99 }
let r2'      = {| ...r2 |}               // {| C = 3; D = 4 |}
let r3'      = { ...r1'; ...r2' }        // { A = 1; B = 99; C = 3; D = 4 }
let r3''     = {| ...r1; ...r2 |}        // {| A = 1; B = 2; C = 3; D = 4 |}
let r3'''    = {| ...r1'; ...r2' |}      // {| A = 1; B = 99; C = 3; D = 4 |}

• Language suggestion: Spread operator for F# fsharp/fslang-suggestions#1253
• RFC discussion: [RFC FS-1151] Spread operator for F# fsharp/fslang-design#806

This PR is meant to begin probing the "spread operator for objects" space (especially the set algebra and associated mechanics) while leaving room for implementing more of the scenarios outlined in fsharp/fslang-suggestions#1253 later. For example, should this prove viable, I would expect one of the next additions to be support for spreading non-records into records, i.e., mapping regular class/struct/interface properties/fields to record fields; this PR explicitly disallows that to ensure that we are free to add it later.

Checklist

• Release notes entry updated
• Fix any regressions
• Enough™ tests
  • Spreads in (mutually) recursive types
  • Effects
• Add placeholder for without in parser?
• RFC: [RFC FS-1151] Spread operator for F# fsharp/fslang-design#805
• Address remaining TODOs (mostly AST traversal branches)
• Clean up/refactor

[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.100.md	No release notes found or release notes format is not correct
LanguageFeatures.fsi	docs/release-notes/.Language/preview.md	No release notes found or release notes format is not correct

[nojaf]

Amazing work! I was literally asking @edgarfgp a few days ago if we had something like type R3 = { ...R1; ...R2; E : int } in F#!

[T-Gro]

I see two options on how to integrate all forms of spreads:

• 1: Have a dedicate feature/spreading branch and have PRs merging incremental additions to it. This is how bigger features have been done in the past.

• 2: Add the features to main (make us of the fact that NET10 development is close now, and within short time main will mean net11 already -> plenty of time) via dedicate feature switches. And prior to major release time, decide on the feature set to bring in.

Option 1 has advantages in terms of overall feature marketing and explain-ability to F# users.
Option 2 would give us options to dogfood selected pieces via preview SDK, and gather feedback sooner. (with the usual preview disclaimer of those bits being subject to potential change).

In this PR , Record spreads IMO form a coherent addition to the language and could be integrated standalone (= I would vote for option 2 here, i.e. integrate to main once main means net11)

[brianrourkeboll]

I'd be a bit afraid that a feature branch would take a lot of effort to keep conflict-free. But yes, I understand the desire to avoid a situation like from-end slicing where the feature is never enabled but the extra code complexity sticks around (someday I will revive my slice branch that will address that particular problem, though 🙂).

[T-Gro]

I am with you on merging it to main as long as we can imagine final (e.g. at major .NET release time) user communication for that specific subset.

(sensible cuts I could imagine being separately release-able as of now basically follow the sections of the RFC Discussion: LanguageFeature.RecordSpread, ObjectIntoRecordSpread, InterfaceImplementationSpread, SpreadingPattern )

[dsyme]

@brianrourkeboll Great to see work starting in this direction!

[vzarytovskii]

I know it's early (and it's a draft), but I wonder if instead of boolean flag, it can be represented by the struct DU? Intention will be a bit more readable.

[brianrourkeboll]

I realize you probably meant something like type FromSpreadOrNah = FromSpread | Nah, but since we technically already had that information in scope anyway...

c61dbf4

It got a bit invasive, though.