[RFC FS-1151] Spread operator for F#

[brianrourkeboll]

Discussion thread for RFC FS-1151: #805

• Language suggestion: Spread operator for F# fslang-suggestions#1253
• Proposed implementation:
  • Record spreads: Spread operator { ...expr }, { ...ty } for records dotnet/fsharp#18927

Subthreads

Links to subthreads below for focused discussion on subtopics:

• Type definitions
• Expressions
• Patterns (?)
• .. versus ...
• Alternatives
• Tooling
• Errors & warnings

Not everything mentioned here is equally likely to be a good idea to implement.

I am personally in favor of:

1. Record type spreads.
2. Interface implementation spreads in type definitions and object expressions.
3. Spreading into nominal record expressions.
4. Spreading into anonymous record expressions.
5. Spreading in collection and computation expressions.
6. Maybe spreading in certain specific pattern scenarios.

[brianrourkeboll]

Type definitions

Subthread for discussing spreads in type declarations/definitions.

Record type spreads

In record type declarations, ...SrcTy in type DestTy = { ...SrcTy } implies the union of the fields of SrcTy with any additional fields declared in DestTy.

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

Duplicate field names derived from spreads are allowed in type declarations. Duplicate field names arising from explicit field declarations remain disallowed.

type R1 = { A : int }
type R2 = { ...R1; A : string }   // Allowed.
type R3 = { A : int; A : string } // Still not allowed.

The rightmost instance of a field with a given name, whether from explicit declaration or type spread, wins out and shadows any leftward fields with the same name.

type R1 = { A : int }
type R2 = { ...R1; A : string } // `A : string` wins out over `A : int` from `...R1`.

type R1 = { A : int }
type R2 = { A : string }
type R3 = { ...R1; ...R2 } // `A : string` from `R2` wins out over `A : int` from `R1`.

A suppressible warning is emitted when the intent is less clear, e.g., when a field from a spread shadows a field with the same name that is explicitly declared to the left:

type R1 = { A : int }
type R2 = { A : string; ...R1 }
------------------------^^^^^
warning FSXXXX: Field 'A: int' from spread type 'R1' shadows the explicitly declared field 'A: string` with the same name.

Generic type parameters must be passed through to spreads:

type R1<'a> = { A : 'a; B : string }
type R2<'a> = { X : 'a; Y : string }
type R3<'a> = { ...R1<'a>; ...R2<'a> }

type R1<'a> = { A : 'a; B : string }
type R2<'a> = { X : 'a; Y : string }
type R3<'a, 'b> = { ...R1<'a>; ...R2<'b> }

Attributes on generic type parameters must match:

type R1<[<Measure>] 'a> = { A : int<'a> }
type R2<[<Measure>] 'a> = { ...R1<'a> }

Constraints on generic type parameters must match:

type R1<'a when 'a : comparison> = { A : 'a }
type R2<'a when 'a : comparison> = { ...R1<'a> }

Interface implementation spreads

Type definitions

type IA =
    abstract A: int -> int

type IA =
    abstract A: int -> int
    abstract B: int -> int

type A () =
    interface IA with
        member _.A x = x + 1

type B (a : IA) =
    interface IB with
        ...a
        member _.B x = x - 1 

This should also probably work with a self-alias (thanks for bringing the scenario up, @Happypig375):

type IA =
    abstract A: int -> int

type IB =
    abstract A: int -> int
    abstract B: int -> int

type B () as this =
    member _.A x = x + 1
    interface IA with ...this // uses the above implementation of A
    interface IB with
        ...this // uses the above implementation of A
        member _.B x = x - 1 

Object expressions

Spreads in object expressions would work similarly to how they would in type definitions:

type IA =
    abstract A: int -> int

type IA =
    abstract A: int -> int
    abstract B: int -> int

let a =
    { new IA with
        member _.A x = x + 1 }

let b =
    { new IB with
        ...a
        member _.B x = x - 1 }

[vzarytovskii]

Also, question - how do we deal with attributes? Merge them? Prefer the rightmost?

Did I miss and it's covered somewhere already?

Attributes are copied over. If there is shadowing, the rightmost instance wins in all respects (type, attributes, generic parameters + constraints, etc.). In my PR, this is accomplished by basically copying the RecdField while freshening the range and type instantiation.

type R1 = { [<Attr1>] A : int; [<Attr1>] B : int }
type R2 = { ...R1; [<Attr2>] A : string }

In the above contrived example, R2.A has type string and [<Attr2>], i.e., the explicit rightward declaration of A in R2 fully shadows R1.A from the spread; R2.B has type int and [<Attr1>] from the spread.

That might be a really fun experience. I imagine it can go really wrong with some attributes, for example FieldOffset attribute. We should probably add either tests or some explicit attributes blocklist/warnlist.

[brianrourkeboll]

Also, question - how do we deal with attributes? Merge them? Prefer the rightmost?
Did I miss and it's covered somewhere already?

Attributes are copied over. If there is shadowing, the rightmost instance wins in all respects (type, attributes, generic parameters + constraints, etc.). In my PR, this is accomplished by basically copying the RecdField while freshening the range and type instantiation.

type R1 = { [<Attr1>] A : int; [<Attr1>] B : int }
type R2 = { ...R1; [<Attr2>] A : string }

In the above contrived example, R2.A has type string and [<Attr2>], i.e., the explicit rightward declaration of A in R2 fully shadows R1.A from the spread; R2.B has type int and [<Attr1>] from the spread.

That might be a really fun experience. I imagine it can go really wrong with some attributes, for example FieldOffset attribute. We should probably add either tests or some explicit attributes blocklist/warnlist.

Hmm, I mean yeah, it is admittedly quite unlikely that spreading types that use FieldOffset would lead to correct code. But arguably you're already on your own when you use FieldOffset anyway (and the compiler already warns you about unverifiable code as soon as you add StructLayout)...

[Lanayx]

I think there's nothing wrong with spreading FieldOffset when you know what you are doing. I can easily imagine set of structs, all with explicit offsets that must share first several fields. With shadowing however it will be a dangerous story.

[brianrourkeboll]

@dsyme #806 (reply in thread)

Just to note that you may need strong limitations on type recursion.

The F# compiler "loads"/"defines" a self-referential collection of types in about 12 phases. The expansion of "..." types will have to happen at one of these phases (as I assume the "..." don't be maintained into the TypedTree - this is going to be an expansion thing).

Depending which phase is the "right" phase to do this expansion there will be some limitations on what is/isn't allowed w.r.t. recursion.

The current version of the expansion is rather naïve and is done alongside the typechecking of regular record fields:

| SynFieldOrSpread.Field synField :: fieldsAndSpreads ->
    // Typecheck a record field declaration.
    // …

| SynFieldOrSpread.Spread (SynTypeSpread (ty = ty; range = m)) :: fieldsAndSpreads ->
    checkLanguageFeatureAndRecover g.langVersion LanguageFeature.RecordSpreads m

    let (spreadSrcTy, tpenv), error =
        try TcType cenv NoNewTypars CheckCxs ItemOccurrence.UseInType WarnOnIWSAM.Yes envinner tpenv ty, false with
        | RecoverableException e ->
            errorRecovery e ty.Range
            (g.obj_ty_ambivalent, tpenv), true

    // Typecheck the fields from a spread source type.
    // …

That definitely doesn't give us what we want:

mut_rec.mp4

I'll keep poking around and see what I can do.

Edit: I was able to get something working, though it needs a few tweaks.

[brianrourkeboll]

All right, I was able to get the checking for cyclical spreads working (and fix a spot I had missed along the way).

[brianrourkeboll]

Expressions

Subthread for discussing expression-level spreads.

Spreads into nominal records

Spreads into nominal records are constrained by the set of fields defined in the target nominal record type. Missing fields in the source expression's/expressions' type(s) must be specified explicitly; extra fields in the source expression's/expressions' type(s) are ignored.

type A =
    { X : int
      Y : int }

type B =
    { Z : int }

type C =
    { X : int
      Y : int
      Z : int
      Extra : string }

let a = { X = 1; Y = 2 }
let b = { Z = 3 }
let c = { ...a; ...b; Extra = "four" }

From other nominal or anonymous records

From other object types

TODO

Spreads into anonymous records

From other nominal or anonymous records

type R1 =
    { A : int
      B : string }
    member _.Lol = 99

type R2 = { ...R1; C : string }

let r1 = { A = 3; B = "4"; Q = 99 }
let r2 = { A = 5; B = "6"; C = "haha" }

let r1AndR2 = {| ...r1; ...r2 |}

From other object types

TODO

Spreads in collection or computation expressions

In collection expressions and computation expressions, ... becomes a new synonym for yield!:

let xs = [10..20]
let ys = [1; 2; 3; ...xs]

≡

let xs = [10..20]
let ys = [1; 2; 3; yield! xs]

While yield! and return! currently partially share a representation in the AST, (SynExpr.YieldOrReturnFrom), I do not see a reason to use ... as an equivalent to return!.

More (TBD)

...

[T-Gro]

The r1AndR2 case show a scenario with inherited/spread duplicity.
The fields and duplicates are known at compile-time, values not.

I would considered "conflict resolution" to be a separate sub-topic, whose resolution would consistently apply to other occurrences of conflicts.

1. First wins?
2. Last wins? (i.e. spreading works like overwriting)
3. Turn a scalar into a tuple (since the duplicity is compile-time detected) ?
4. Disallow duplicates alltogether without any resolution mechanism (I would personally be against this - I would prefer a consistent ruleset with coding patterns allowing to express preference. let r1AndR2 = {| ...r1; ...r2 ; .. r1.A|} // somewhat overwrite A` field with the value from r1 ?)
5. Either of 1/2 with a special rule of "better wins" for optional containers like Option,Result,nulls - this is way to opinionated, I agree.

[dsyme]

Note about effects. Consider this

let r1 = { A = 3; B = "4" }
let r2 = { D = 5; E = "6" }
let r1AndR2 = {| 
    ...(printfn "hello", r1);
    C: (printfn "world"; c);
    ...(printfn "today", r2)
|}

You will need an elaboration into TypedTree that ensures effects only happen once and in the right order. You might need this:

let r1AndR2 = 
    let r1v = (printfn "hello", r1)
    let cv = (printfn "world"; c)
    let r2v = (printfn "world", r2)
    {| A: r1v.A
       B: r1v.B;
       C: cv;
       D: r2v.D;
       E: r2v.E |}

I think this is coherent an implementable and it may be what you already heve. The existing record initialization code is pretty convoluted but hopefully this can be fitted in there OK.

[brianrourkeboll]

Hmm. And then what about something like this?

let r1 = {| A = 1 |}
let f () = printfn "lol"; r1
let r2 = {| ...f (); ...f (); A = 2 |}

r1.A would never actually be used in r2, since the trailing explicit A = 2 would shadow it. But I suppose it would still be expected that f () would be evaluated twice. That would accord with, e.g., JavaScript's behavior in the same situation:

const o1 = { a: 1 };
const f = () => { console.log('lol'); return o1; };
const o2 = { ...f(), ...f(), a: 2 }; // Logs twice, but o2.a is 2.

[brianrourkeboll]

I went ahead and implemented this here: 5f8ff64

I.e., evaluate each spread source expression exactly once, binding to a mutable local if necessary, even if all fields derived from the expression are shadowed and thus never actually used.

[T-Gro]

This makes the most sense from a correctness standpoint 👍

[brianrourkeboll]

Patterns (?)

Subthread for discussing pattern-level spreads.

Records

Record patterns already allow specifying only a subset of fields and ignoring those unuttered. Would we allow ... as well?

Anonymous records?

fsharp/fslang-suggestions#713 (comment)

Could this be implemented via SRTPs?

let f x =
    match x with
    | {| A = 3; B = 4; ... |} -> …

let f x =
    match x with
    | {| A = 3; B = 4; ...rest |} -> …

Tuples?

let tuple = 1, 2, 3, 4, 5, 6, 7
let x, y, ...rest = tuple

Arrays?

match xs with
| [|...; 3; 4|] -> true
| _ -> false

match xs with
| [|...rest; 3; 4|] -> f rest
| _ -> false

Lists?

We already have

match xs with
| 3 :: 4 :: _ -> true
| _ -> false

Would we add

match xs with
| [3; 4; ...] -> true
| _ -> false

?

What about

match xs with
| [...; 3; 4] -> true
| _ -> false

, which would be $O(n)$?

Or

match xs with
| [...rest; 3; 4] -> f rest
| _ -> false

?

More (TBD)

...

[T-Gro]

I do get standalone ... to indicate the rest is ignored.
The ... rest looks like it should be binding something and would indeed lead us to anti-spreads as well, for a possible very narrow use case?

[Happypig375]

Don't you find it inconsistent that this proposed anonymous record pattern must be complete by default and the spread is required to make it non-complete, whereas the nominal record pattern is non-complete by default?

[brianrourkeboll]

Don't you find it inconsistent that this proposed anonymous record pattern must be complete by default and the spread is required to make it non-complete, whereas the nominal record pattern is non-complete by default?

Yes, they would indeed be inconsistent.

As I mention in fsharp/fslang-suggestions#713 (comment), though, some form of fsharp/fslang-suggestions#968 could subsume both. I think I would probably lean towards that instead.

[Happypig375]

Yea, in that case just go directly for object patterns, the anonymous record pattern isn't needed.

[T-Gro]

There is a big difference in type checking and type inference though - even though the record pattern is syntactically incomplete, it does bind a single named type.

I am aware of SRTP proposals to desugar the anon pattern into. But I am not yet convinced that using SRTPs as a vehicle to power basic features is deserved (especially thinking about debuggability and troubleshooting).

[Happypig375]

Prefix .. operator is also distinguishable from infix .. operator (given that we allow 1 ..2 to change meaning). We can potentially save a dot and align with C#.

[Happypig375]

@T-Gro Any input from a backcompat perspective?

[T-Gro]

(..) is an user-definable operator which does not prohibit a single-argument declaration, I am not sure if we could guarantee not breaking anyone. (...) avoids that and is also aligned with TypeScript.

[brianrourkeboll]

(..) is an user-definable operator which does not prohibit a single-argument declaration, I am not sure if we could guarantee not breaking anyone.

Even though you can define it as a single-argument function, it won't actually parse when used in prefix form; you can only invoke it like (..) x, not like ..x.

The only place ..expr is currently syntactically valid is in indexers: xs[..i]. That would only cause compatibility issues with some of the more unlikely potential uses involving tuples or function/method arguments, like currying/uncurrying (fsharp/fslang-suggestions#1253 (comment)), spreading tuples into other tuples, spreading records or tuples as method args, spreading into param arrays, etc.

So I think that .. would be syntactically viable if we were confident that we never wanted to use spreading for anything tuple or arg-related.

[Happypig375]

or you can also just define spreading into an indexer with an integer argument as a ranged lookup?

[brianrourkeboll]

or you can also just define spreading into an indexer with an integer argument as a ranged lookup?

I'm not sure what you mean. Right now, you can define a GetSlice method with nearly any signature you want (or indeed multiple overloads with different signatures).

type T =
    | T
    member _.GetSlice _ = 99

// These are all currently syntactically valid.
T[..null]
T[..T]
T[..1000]
T[..()]
T[..3, ..99]
T[..(1, 2, 3)]
T[..[1, 2, 3]]

Changing the effect of .. on its argument(s) in indexers in any way would be a breaking change.

[brianrourkeboll]

Alternatives

Subthread for discussing alternatives: pros and cons.

with

type R1 = { A : int; B : int }
type R2 = { R1 with C : int; D : int }
type R3 = { R1 with R2 } // ?

let r1 = { A = 1; B = 2 }
let r2 = { r1 with r2 }

Pros

• The with keyword already exists and its usage overlaps with that proposed for ....

  let r1 = {| A = 1; B = 2 |}
  let r2 = {| ...r1; C = 3 |} // = {| r1 with C = 3 |}

Cons

• with is not as universally applicable as ..., e.g., it would not make sense in patterns...
• with is both more semantically and syntactically ambiguous and less composable in various scenarios, e.g.,

  let r1 = {| A = 3; B = 4 |}
  let r2 = {| C = 5; D = 6 |}
  let r3 = {| ...r1; ...r2 |}         // Would this be {| r1 with r2 |}?
  let r4 = {| ...r1; E = 99; ...r2 |} // How would this work with `with`?

Type providers

E.g., fsharp/fslang-suggestions#212 + fsharp/fslang-suggestions#154 for type spreads.

Pros

• Potentially even more powerful.

Cons

• Almost certainly harder to implement.
• Only solves type spreads, not expression spreads (or other proposed uses).

Mapped types

Something akin to TypeScript's mapped types:

• Mapped types microsoft/TypeScript#12114
• https://www.typescriptlang.org/docs/handbook/2/mapped-types.html

Type spreads are basically a small subset of mapped types that don't permit anything other than a direct, memberwise mapping.

TypeScript's version of mapped types includes many aspects particular to how TypeScript (and JavaScript) work. Presumably an F# version would have F#- (and .NET-) specific analogues for many of those (e.g., whether/how to map .NET attributes, generic constraints, etc., etc.).

Pros

• Could be extremely powerful, subsuming spreads, Allow type providers to generate types from other types [ RFC FS-1023 ] fslang-suggestions#212, many use-cases for Support Source Generators fslang-suggestions#864, and many other existing and proposed features.

Cons

• Only addresses type spreads, not expression spreads (or other proposed uses).
• Potentially massive in scope.
• Would require a huge investment in tooling.
• Would likely usher in an altogether new style of type-level programming.

[kerams]

First thing that comes to mind

let r4 = {| r1 with r2; E = 99 |}
let r4 = {| r1 with r2 with E = 99 |}

Maybe another con - the proposed use of with signifies extending something, while the record update syntax replaces existing values. These are slightly different concepts.

[brianrourkeboll]

Yeah, ... in records/anonymous record expressions would imply a (compile-time) set union operation where the rightmost instance of a field would win out (as in, e.g., JavaScript and TypeScript).

[brianrourkeboll]

Tooling

Rendering & signatures of record types containing spreads

Rendering

F# tooling currently lists the fields (or a truncated subset thereof) of a record type definition on hover or when passed to F# interactive.

What should the tooling show for a record type that includes a spread? E.g., given

type R1 = { A : int; B : int }
type R2 = { ...R1; C : int }

should the tooling indicate that R2 has any relationship to R1?

Recall that the relationship of R2 to R1 implied by ...R1 is compile-time only and indicates only that R2 contains all of the fields of R1; it does not imply inheritance.

In such a case, should the tooling show:

1. The spread alone:

   type R2 =
       { ...R1; C : int }

2. An inlining of the spread without mention of the source type:

   type R2 = { ...{ A : int; B : int }; C : int }

3. A full expansion of the spread without mention of the source type:

   type R2 = { A : int; B : int; C : int }

4. Or some form of both:

   type R2 = { ...R1 (A : int; B : int); C : int }

?

Signatures

The signature of a record built from spreads would surely be the fully expanded version with no mention of the underlying spreads, i.e., given the definition

type R1 = { A : int; B : int }
type R2 = { ...R1; C : int }

the signature would be

type R1 = { A : int; B : int }
type R2 = { A : int; B : int; C : int }

Code fixes & refactorings

Would it be feasible and worthwhile to offer a refactoring to convert a spread to explicit redefinitions or delegations? This could be useful if the developer decides that there should no longer be a compile-time relationship between the source of the spread and the target, but wishes to keep all or most of the definitions, implementations, or values implied by the spread.

[T-Gro]

For all different perspectives ( public API, reflection, cross-compilation,..), should spreads be considered an implementation detail and be fully interchangeable with their fully written counterparts?

i.e. how does replacing a type composed from spreading to a handwritten one affect aspects of compatibility?

[brianrourkeboll]

should spreads be […] fully interchangeable with their fully written counterparts?

Yes.

[brianrourkeboll]

Errors & warnings

Shadowing & duplicates

What is the rationale for why the error range for duplicate nominal/anonymous record fields currently points to the first instance rather than to the first duplicate instance? It would seem to me that it is the duplicate field that is in error, not the first one.

type R = { A : int; A : int }
let r = { A = 1; A = 1 }
let a = {| A = 1; A = 1 |}

With the addition of spreads, I wonder whether it might make sense to change that. Take this example:

type R1 = { A : int; B : string }
type R2 = { A : decimal }
type R3 = { ...R2; A : string; ...R1; A : float; A : decimal }

I would personally expect the warnings and errors to look something like this:

The first instance of A in R3 comes from ...R2; the second comes from the explicit A : string, which is allowed to shadow the A from ...R2 without warning; we then however want to warn on the A from ...R1 shadowing the preceding explicit A (shadowing an explicit declaration via a spread is a bug, or else why bother with the explicit declaration?); we then also want to error on the following two explicit duplicate As.

At least, that's what makes sense to me. We could alternatively just warn/error on the first instance of A like the existing logic, in this case the A coming from ...R2. But that seems less clear.

If we made this change, should it only happen if there are spreads present, while using the old logic otherwise? Or should the existing error range logic for explicit duplicate fields alone be updated as well?

Recursion

TODO

[brianrourkeboll]

#806 (reply in thread)

I feel we should point the range of the diagnostics to the one being shadowed, or point to both using a hint similar to see also text where a diagnostic carries 2 ranges, this is used in ConstraintSolver already.

Hmm, this is basically what the existing behavior is without spreads in the mix (as noted above), although the existing diagnostics just talk about duplicates and do not frame it as "shadowing." My rationale for wanting to show the diagnostic on the source of the shadowing rather than on the field being shadowed was mainly that, for spreads, if we showed the diagnostic only on the field being shadowed, the actual source of the shadowing might not be trivial to find at a glance, since the field name itself would not exist in the source.

I.e., here, if we show the warning on R3.A, you can't see the "duplicate" instance of A by looking at the definition of R3 alone; you'd need to inspect the definition of R1 as well (or hover over ...R1 to see that R1 also had a field A). But showing the warning on ...R1 makes it clear where the shadowing is happening:

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

This is what my PR currently does:

This is what it would look like with the warning on the field being shadowed instead (we'd probably want to adjust the wording, but still):

In either case, we could include a "see also" in the message (or indeed emit two separate diagnostics, one for each). But it is not clear to me that there would always be an obvious action for a developer (or LLM) to take (delete the explicit declaration, delete the spread, or reorder them), since it would depend entirely on the intent. The reason for the warning is to inform the developer that they should make a decision: it is very unlikely that the developer intends to shadow an explicitly declared field, since once shadowed it is dead code and can only mislead the reader, so they should either make the explicit declaration shadow the field from the spread by moving the explicit declaration after the spread, or else consider whether the explicit declaration is needed at all.

[brianrourkeboll]

#806 (reply in thread)

In all those cases, whether it's accidental add or remove field, compiler won't show any hint that behavior of the system has just changed.

Hmm. I hope I'm not being the guy saying the equivalent of "just be good at writing C and you don't need to worry about memory safety bugs" or "you're holding it wrong" 🤣🤣, but in my mind the use-case for a record type spread is when the developer intends for the contents of the source type to be copied over to the target type at compile time — including when recompiling after a potential update of the source type — unless otherwise specified via shadowing.

If the developer does not intend for such a relationship to hold — if they do not want any changes made to the source type to affect the target type after the first compilation — then a spread is not the right solution, because the spread syntax, through the act of uttering the source type's name, implies that the target type has a compile-time dependency on the source type and wants its structure to be derived from the source type when (re-)compiled.

The scenarios you outline above, where you want to be able to derive one type's structure from that of another but want to be able to explicitly audit any changes that might be brought into the target from the source upon recompiliation, almost sound like they might be better served by source generation of some kind, where the generated source is committed to source control, and the diff can be reviewed when it is regenerated.

I admit that it is possible that scenarios like yours could be more common than scenarios like those that I have in mind (where you generally want any changes to the source to be brought into the target), but my instinct is that they are not.

But perhaps the best solution to this dilemma is to get an early version of this feature merged as a preview feature so that people can try it out to see when, where, and whether it is actually useful 🙂🙂.

[Lanayx]

but in my mind the use-case for a record type spread is when the developer intends for the contents of the source type to be copied over to the target type at compile time — including when recompiling after a potential update of the source type — unless otherwise specified via shadowing.

I see it differently - I'd use type-level spread in situations where domain dictates duplicate fields in many similar DTO objects (like CreatedAt field in db tables, or error code in HTTP dtos), and they will never be copied from one to another. I see instance-level spread as a useful tool for copying content.

The scenarios you outline above, where you want to be able to derive one type's structure from that of another but want to be able to explicitly audit any changes that might be brought into the target from the source upon recompiliation, almost sound like they might be better served by source generation of some kind, where the generated source is committed to source control, and the diff can be reviewed when it is regenerated.

Right, codegen can be useful, since types representing tables, dtos, or messages can be generated from db schema, openapi schema or protobuf schema in theory. But in practice, such codegen to F# tools often either not exist or don't have good enough DX and maintenance, so using spreads on type could really be a powerful and simple solution for those cases.

But perhaps the best solution to this dilemma is to get an early version of this feature merged as a preview feature so that people can try it out to see when, where, and whether it is actually useful

That's why I wanted to start with disallowing type-level shadowing (or at least warnings) and to add it only if there is interest and solid usecases. Doing it in opposite way is impossible - once you allow something, you can't disallow it in the next version. Preview doesn't solve this issue - it takes years to build large systems where amount of DTOs is large enough for such accidental mistakes to start happening, so users will start feeling the pain.

[brianrourkeboll]

but in my mind the use-case for a record type spread is when the developer intends for the contents of the source type to be copied over to the target type at compile time — including when recompiling after a potential update of the source type — unless otherwise specified via shadowing.

I see it differently - I'd use type-level spread in situations where domain dictates duplicate fields in many similar DTO objects (like CreatedAt field in db tables, or error code in HTTP dtos), and they will never be copied from one to another. I see instance-level spread as a useful tool for copying content.

Sorry, by "contents of the source type" there I meant "fields of the source type."

The scenarios you outline above, where you want to be able to derive one type's structure from that of another but want to be able to explicitly audit any changes that might be brought into the target from the source upon recompiliation, almost sound like they might be better served by source generation of some kind, where the generated source is committed to source control, and the diff can be reviewed when it is regenerated.

Right, codegen can be useful, since types representing tables, dtos, or messages can be generated from db schema, openapi schema or protobuf schema in theory. But in practice, such codegen to F# tools often either not exist or don't have good enough DX and maintenance, so using spreads on type could really be a powerful and simple solution for those cases.

I didn't mean code generation from a DB schema to F# types, I meant code generation of one F# type from another — i.e., the same thing that the spread operator is doing under the hood, but expanded into explicit, committable source code so that any subsequent diffs can be reviewed.

But perhaps the best solution to this dilemma is to get an early version of this feature merged as a preview feature so that people can try it out to see when, where, and whether it is actually useful

That's why I wanted to start with disallowing type-level shadowing (or at least warnings) and to add it only if there is interest and solid usecases. Doing it in opposite way is impossible - once you allow something, you can't disallow it in the next version. Preview doesn't solve this issue - it takes years to build large systems where amount of DTOs is large enough for such accidental mistakes to start happening, so users will start feeling the pain.

There is interest in shadowing from me at least :)

We could start with the preview feature allowing shadowing: that way, at least we could get early feedback if people try it out and it is definitely a bad idea. If we don't allow it even in preview, then it remains a purely hypothetical problem. But if we allow it during preview, we can reassess and still decide to make shadowing an error before moving the feature out of preview if we aren't confident one way or the other at that point.

[Lanayx]

Thank you for responding to my comments, appreciate that you hear my point of view! I think we can agree that whether it should be a warning or not should come from the larger community. Should it be enabled in preview so users can taste it better - idk, maybe. I personally won't be using type-level spreads in my projects in preview (since I'm afraid of shadowing bugs), but it's possible that others will and leave feedback, so it's up to you :)