Spread operator for F#

[dsyme]

I propose we consider the merits of a spread operator for F#

...expr

It would be used for

• building records and anonymous records from spreadable things (subsuming with and this suggestion)
• building object expressions from spreadable things (subsuming this suggestion)
• implementing interfaces from spreadable things (subsuming this suggestion)
• perhaps other things

Records

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" }

Anonymous records

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

Object expressions

type IA =
    abstract A: int -> int
type IAB =
    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 }

Interface implementations

type IA =
    abstract A: int -> int
type IAB =
    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 

The existing way of approaching this problem in F# is explicit re-delegation.

Technical details?

Fundamental technical questions are

• What is considered spreadable?
  • Certainly objects, records, anon records
  • But what of tuples, unions and anything with methods or properties
• What spreadable items are provided by a spreadable thing?
  • Assume spreadable things always have nominal known type
  • Certainly record fields
  • Certainly object methods, properties.
  • Possibly object events (very rarely used though)
  • What of extension methods and properties?
  • What about F# modules?
  • Is any type information propagated into the spreadable things from the thing being constructed?
• What requirements emerge from the target of spreadable items?
  • Assume target of spreadable items always have nominal known type
• How exactly are the spreadable items used to satisfy the requirements?
• How about generics?
  • Are values of a SRTP-constrained type considered spreadable?
  • Are values of a class-constrained generic type considered spreadable?

For example

• Can you spread a record into an object expression? (Yes)
• Can you spread an object into a record? (Yes)
• If an object has a generic method M<T> : T -> T, can that be used to implement a requirement M: int -> int through type specialization? (TBD)

Patterns?

Should a spread operator be allowed in patterns? e.g.

match r with 
| {| A = a; ...rest |} -> ...

Initially there would I think be no need for this.

Types?

How about type syntax? e.g.

type A = {
    X: int
    Y: int
}
type B = {
    Z: int
}
type C = {
    ...A;
    ...B;
    Extra: string
}
let a = { X = 1; Y = 2 }
let b = { Z = 3 }
let c = { ...a; ...b Extra = "four" }

Spreading record types into other record types seems tempting, but note this would not give rise to subtyping. But then can you spread object types into record types? Seems like a step too far?

Collections?

Spread operators in other languages usually work with

• collections
• tuples
• spreading a spreadable-thing as a group of named parameters x.SomeMethod(...record_of_args)
• ParamArray/params (to explicitly pass a collection as a ParamArray arg, which is currently done via inference)

Bat all of this is necessarily desirable for a spread operator in F#, though each should be considered and if they aren't supported good diagnostics should be given directing people to the right way to do things.

Pros and Cons

The advantages of making this adjustment to F# are conceptual efficiency, introduction of a littler structural matching

The disadvantages of making this adjustment to F# are

• additional feature
• some subtle corner cases
• won't work 100% as expected from other languages.
• it may lead to a cascading set or requirements for using spread operators and related structural manipulations in generic code.

Extra information

Estimated cost (XS, S, M, L, XL, XXL): L

Affidavit (please submit!)

Please tick this by placing a cross in the box:

• This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
• I have searched both open and closed suggestions on this site and believe this is not a duplicate
• This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

• This is not a breaking change to the F# language design
• I or my company would be willing to help implement and/or test this

For Readers

If you would like to see this issue implemented, please click the 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.

[brianrourkeboll]

I suppose it could technically subsume yield! in computation expressions as well.

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

[dsyme]

I suppose it could technically subsume yield! in computation expressions as well.

Yes, it could. Which then raises the question of return! too.

[baronfel]

A 'rest' operator for list-like patterns would be very helpful - right now list is privileged in terms of syntax because it can easily be deconstructed into parts of a certain length and 'the rest' - other list-like types (those that are indexable) would be more usable if they has a way to achieve the same result.

[dsyme]

A 'rest' operator for list-like patterns would be very helpful - right now list is privileged in terms of syntax because it can easily be deconstructed into parts of a certain length and 'the rest' - other list-like types (those that are indexable) would be more usable if they has a way to achieve the same result.

Yes also allows a "match at end" syntax for arrays and lists.

[cartermp]

RIP tooling logic for handling dots 😄

[Lanayx]

I'd like to see DUs added to suggestion as well on type level, so one can use

type One = 
    | X of int 
    | Y of string
    
type Two =
    | ...One
    | Z of string

The benefits are less prominent on instance level, but also usable

type One = 
    | X of int 
    | Y of string
    
type Two =
    | X of int 
    | Y of string
    | Z of string
    
let x: One = X 1
let y: Two = ...x

[smoothdeveloper]

@dsyme, would you mind expanding a bit on the compile time and possibly runtime semantics you envision for the concrete implementation of this on CLR?

Also, would you mind sharing about the background / prior art, that is inspiring this feature?

Spreading record types into other record types seems tempting, but note this would not give rise to subtyping. But then can you spread object types into record types? Seems like a step too far?

Not having support for spreading at type level seems it would force redundant work on type definition, when the author desires to always map all the properties; design-wise, it would not be encouraged, but for the use cases of full mapping being ever desired, rather than selective / explicit one. I think it improves semantics of the code to support it on type definition.

@Lanayx example for DU is also good to consider, if records is going to support this.

Spreading object types into records or even a DU case, seems appealing to me, but not needed for first iteration in landing this feature.

This feature would be useful for https://github.com/isaksky/FsSqlDom which maps MSSQL Dom to DU, where bulk of declarations is done in code generation, it could be done with spreadability of object into DU cases.

I'm also seeing use case where it would be possible to explicitly omit some of the things, #762; I think it should prompt question about ... being the best notation; I've considered += { a without PropName1; PropName2 }

it may lead to a cascading set or requirements for using spread operators and related structural manipulations in generic code.

Are you considering some of the SRTP constructs would ideally, need to support a notation describing "spreadability semantics" between any two types or, type to set of types?

Are values of a SRTP-constrained type considered spreadable?

It seems to me, this would be powerful to make selective spread operators, which monomorphizes at compile time.

Are values of a class-constrained generic type considered spreadable?

Given the runtime cost, assuming this would be runtime reflection based, I'd see this as least priority than the SRTP approach (now that SRTP is embraced better, due to IWSAM giving "run for the money" :D), people can use automapper stuff, it seems it can be library based, specific to semantics of CLR, not specific to F#, less added value than SRTP semantics.

some subtle corner cases

Sensing inheritance is going to be headache inducing, I believe for a first approach (in order to get the feature out, for the already known effective use cases), it would be fine to bail out, if there is any kind of clash / ambiguity surfacing from multiple or conflicting inheritance scenarios.

The main issue is that it is still work to verify those cases, and report errors that make sense, but this would allow to defer decisions in this area, while seeing the real world usages and deriving feedback from it for, later, opening those use cases that would be guarded.

[xp44mm]

With this feature, the clone record syntax { a with } will be improved by spread record syntax id<'targetType> { ...a }.

The record spread syntax is similar to javascript, so "record field value shorthands" syntax may be a good feature as well.

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 Extra = "four" //*
let c = id<C>{ ...a; ...b; Extra  } // <- Extra

@brianrourkeboll I agree with you.+1
#973 (comment)

[aaronmu]

Interesting, I think it might improve developer experience a lot.

Would it be possible to spread anon records into a normal record?

type A = { X: int; Y: int; Z: int }

let x = {| X = 1; Y = 2 |}
let y = {| Z = 3 |}

let a = {...x; ...y }

How about combining anon records?

let x = {| X = 1; Y = 2 |}
let y = {| Z = 3 |}
let z = {| ...x; ...y |}

What would happen in the below scenario?

type A = { X: int; Y: int }
type B = { X: int }

let a : A = { X = 1; Y = 1 }
let b : B = { ...a }

Ideally all of these examples just work :-)

[dsyme]

Would it be possible to spread anon records into a normal record?

Yes, that's the intention of the design.

What would happen in the below scenario?

Yes, there could be excess properties. The new object "b" would not have property Y. My understanding is this is different to TypeScript, where all properties are copied across as the JS semantics is used at runtime (TS typing doesn't affect runtime behaviour).

How about combining anon records?

Yes, that would be in scope

[dsyme]

@smoothdeveloper

Not having support for spreading at type level seems it would force redundant work on type definition, when the author desires to always map all the properties; design-wise, it would not be encouraged, but for the use cases of full mapping being ever desired, rather than selective / explicit one. I think it improves semantics of the code to support it on type definition.

I'm a bit ambivalent about support in type definitions. The more "programmatic" type definitions become, the harder they are to understand - to work out what properties are in a type you have to "run the type level program in your head". This is sort of OK for expressions - which are "real" programs and have debugging, printing etc. support - but for type level programs it's all compile-time execution. It's basically similar to many of my concerns about type-level programming I've expressed in the past, e.g. #243

Still we could do expressions first and leave types to later.

[dsyme]

@Lanayx Regarding #1253 (comment) - interesting. I can see there is some kind of potential here, perhaps as a third wave.