Deprecate places where `seq` can be omitted e.g. `{ 1.. 5 }`

[Happypig375]

I propose we make this consistent:

let f = Seq.head
let a = f { 1..6 }
let b = f { 1; 2 } // error FS0740: Invalid record, sequence or computation expression. Sequence expressions should be of the form 'seq { ... }'

Now we don't have to allocate entire lists or arrays just to make sets.

let a = set { 1..6 }
let b = set { 1; 2 } // error FS0740: Invalid record, sequence or computation expression. Sequence expressions should be of the form 'seq { ... }'

The existing way of approaching this problem in F# is

let a = set { 1..6 }
let b = set (seq { 1; 2 })

Pros and Cons

The advantages of making this adjustment to F# are

1. Consistency
2. Convenience
3. Less allocation

The disadvantage of making this adjustment to F# is that this may cause confusion as set here isn't a computation expression. However, syntax can be quickly learnt.

Extra information

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

Related suggestions: (put links to related suggestions here)

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.

[charlesroddie]

Too much of a special case. If seq { 1..6 } requires the seq then set(seq { 1..6 }) should require the seq.

[TheJayMann]

I believe you misunderstood the request. In both seq { 1..6 } and set(seq { 1..6 }), the seq is already optional today. The request is that seq also be optional for { 1;2 } as well.

Also worth noting that { 1..6 } and seq { 1..6 } does not produce the same code, as the former creates Operators.OperatorIntrinsics.RangeInt32(1, 1, 6) while the latter creates Operators.CreateSequence(Operators.OperatorIntrinsics.RangeInt32(1, 1, 6)).

[Happypig375]

Oh, { 1 .. 6 } produces a range. That is interesting actually.

[cartermp]

I think I like this, since it's pretty confusing that you don't need to do seq { x..y } but you need to do seq { x; y }. Since we can't remove the ability to do { x..y } I'd be in favor of this provided there isn't a breaking change.

[dsyme]

Since we can't remove the ability to do { x..y } I'd be in favor of this provided there isn't a breaking change.

TBH I think I'd rather force the addition of seq through a warning or informational message.

There are three cases

1. { x .. y }
2. { 1; 2 }
3. { if true then yield 1 } and other computations

Only (1) allows you to omit seq today. This case snuck through in F# 2.0 and should really have always requried a seq.

However I do like that set and other future collection construction operations can omit the seq without making those full computation expressions. That is, if the seq is being immediately consumed eagerly into a collection construction then I'm happy to omit it. However we have no specific way of telling if that's the case

The reasons I like seq are

1. the laziness is made obvious
2. it makes things distinct from object expressions and record expressions
3. it introduces people to computation expressions.

As an aside (really a different issue) we should consider a .. b in computation expressions more generally - currently these are only allowed in sequence, list, array expressions.

[dsyme]

Approving the variation described here: #1033 (comment)

[brianrourkeboll]

@edgarfgp & @vzarytovskii regarding dotnet/fsharp#17772 and #1033 (comment):

TL;DR

It seems like #1086 (which, incidentally, Don opened after #1033 (comment)) would obviate the need for enabling set { x; y } specifically, and I'd personally rather work towards¹ some version of #1086 in the long run.

My understanding of #1033 (comment) is that, if anything, we should deprecate/discourage bare { start..finish }.

Long answer

This part of #1033 (comment) —

However I do like that set and other future collection construction operations can omit the seq without making those full computation expressions. That is, if the seq is being immediately consumed eagerly into a collection construction then I'm happy to omit it.

— seems like it would be effectively subsumed by #1086 instead.

#1086 would enable

let xs : Set<_> = [ x; y ]

and

let f (xs : Set<_>) = …
f [ x; y ]

and

let f (xs : Set<_>) = …
let xs = [ x; y ]
f xs

That would make it less compelling to enable the omission of seq in

let xs = set { x; y }

since Don implies in

TBH I think I'd rather force the addition of seq through a warning or informational message.

This case [{ x .. y }] snuck through in F# 2.0 and should really have always requried a seq.

that we would not enable

let f (xs : Set<_>) = …
f { x; y }

or

let f (xs : _ seq) = …
let xs = { x; y }
f xs

and would instead still require seq { … } in f (seq { x; y }) and let xs = seq { x; y } for reasons like

• the laziness is made obvious

• it makes things distinct from object expressions and record expressions

• it introduces people to computation expressions.

So #1086 would let us address more scenarios more consistently than would allowing the omission of seq in set { x; y } on its own.

Side note

It is worth remembering that #1086 would still require explicit seq { … } for laziness (as opposed to [ … ]) in both

let xs : _ seq = seq { x; y }

and

let f (xs : _ seq) = … in f (seq { x; y })

as mentioned in #1086 (comment):

The [...] syntax could only really be an eagerly-evaluated collection … it could only be used against collection types that define either an eager builder pattern or an eager create+Add pattern.

That is, [ x; y ] in something like

let xs : _ seq = [ x; y ]

or

let f (xs : _ seq) = …
f [ x; y ]

would still need to eagerly produce a list, even if only for backwards compatibility, since such code is valid today and the expressions in [ … ] could have side effects, etc.

Edit: Addendum

We should also consider what directions we might take with #1044 and #1116 (see also #1317 (comment) and #1317 (comment)).

For example, depending on how far we went in treating start..finish as System.Range (#1044 (comment)), and how we enabled other constructs to support consuming System.Range values, at least some current usages of { start..finish } could potentially be replaced by start..finish.

The syntax start..finish is in fact already treated identically to { start..finish } in some contexts:

SharpLab

let f start finish = for x in start..finish do ignore (float x ** float x) 

SharpLab

let f start finish = for x in { start..finish } do ignore (float x ** float x) 

But if (and I'm not saying we necessarily would or should) we went as far as C# does and supported first-class ranges —

let range = start..finish

— it would seem to be all the more desirable to deprecate { start..finish } in favor of seq { start..finish } to help differentiate the creation of a lazy sequence in something like let range = seq { start..finish } from the creation of a System.Range in let range = start..finish.

Footnotes

1. I would be interested in helping spec it out and/or implement it. ↩