fslang-suggestions icon indicating copy to clipboard operation
fslang-suggestions copied to clipboard

Mixing ranges and values to construct sequences

Open Happypig375 opened this issue 4 years ago • 6 comments

Mixing ranges and values to construct sequences

I propose we allow:

let a = seq { 1..10; 19 }
let b = [-3; 1..10]
let c = [|-3; 1..10; 19|]

The existing way of approaching this problem in F# is

let a = seq { yield! seq { 1..10 }; 19 }
let b = [-3; yield! [1..10]]
let c = [|-3; yield! [|1..10|]; 19|]

It's annoying to have to insert a whole yield! just to add a range.

Pros and Cons

The advantages of making this adjustment to F# are

  1. Conciseness
  2. Convenience
  3. Possibility of optimisation

The disadvantage of making this adjustment to F# is none.

Extra information

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

Related suggestions: (none)

Affidavit (please submit!)

Please tick this by placing a cross in the box:

  • [x] This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
  • [x] I have searched both open and closed suggestions on this site and believe this is not a duplicate
  • [x] 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:

  • [x] This is not a breaking change to the F# language design
  • [x] 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 :+1: emoji on this issue. These counts are used to generally order the suggestions by engagement.

Happypig375 avatar Jun 10 '21 06:06 Happypig375

Seems like a reasonable request to me. Currently, the range syntax for list is

let a = [1..10]

Doesn't seem like much harm, to expand it to be able to include multiple ranges or single value like

let a = [-100; 1..10; 100-120]

Swoorup avatar Jun 10 '21 08:06 Swoorup

Yes this is pretty reasonable, especially now yield is essentially optional

I'll mark it as approved in principle. I'd be interested to know if any problems came from a prototype.

dsyme avatar Jun 14 '21 10:06 dsyme

Marking this as approved in principle

dsyme avatar Oct 13 '21 17:10 dsyme

@edgarfgp A couple things to consider here:

  1. Potential interaction with https://github.com/fsharp/fslang-suggestions/issues/1253. Would

    [1; 2; 3..5]
    

    be equivalent to

    [1; 2; ...3..5]
    

    or

    [1; 2; ...[3..5]]
    

    or both? (Plus [1; 2; yield! [3..5]].)

  2. Potential interaction with any future support for System.Range. If we do this suggestion, would we ever be able to support

    let range = 1..10
    

    if we wanted? (Even though I'm not aware of an existing suggestion for that.)

    For comparison, C# does support

    var range = 1..10;
    

brianrourkeboll avatar May 29 '25 00:05 brianrourkeboll

Would/should this also apply to user-defined computation expressions?

At a glance, it looks like the prototype in https://github.com/dotnet/fsharp/pull/18670 only affects array/list/seq expressions, not regular computation expressions. Does that mean that regular computation expressions (like those defined in https://github.com/fsprojects/FSharp.Collections.Builders, for example) couldn't use this new feature (i.e., they wouldn't implicitly have yield! added)? Should it apply there, too? If it did, would it have any interaction with https://github.com/fsharp/fslang-suggestions/issues/1116?

I don't know the answer myself, but it's another thing that seems like it might be worth thinking about.

brianrourkeboll avatar Jun 07 '25 22:06 brianrourkeboll

Right now I cannot imagine potential breaking changes for "normal CE code" this could cause, and it is only natural to bring collection expressions and CEs together. After all, I personally see it as an historical+implementation detail that they are built into the compiler separately and not a library provided CE with resumable code.

I assume a hypothetical piece of CE code, e.g. one overriding (..) operator, could be broken by this (maybe a type which is also a sequence of itself, and the change would cause implicit flattening? But that seems possible even for normal collection builders - somewhat similar to this: https://sharplab.io/#v2:DYLgZgzgNALiBOBXAdgHwPYAcCmyAEAygJ4QzYC2AsAFBa6ElnkB0AwusMNgMYwCW6ZBBp18xUhTYcuvAUOYBxXNnh9uNGjCI48ADQAU2LuVwwIIPXmB9SASjwBeGnhd4A9G7wBRAB6Z0ENh4MAAWQSgAJirARHzIAOZWNjDOribkAEYqwSE2zF7GphCOeEYURRrUru6eAJLkmIXIMHi1XsiIJvAAhhlcADy6AHypLnFk8GDd3EFtHV29A8N4AO58oaPVeOlZ8Dl5SjDtnSrdMOjw+vZOVVt3+qF5BeXNxSBDrccLfdiDQ7aKbBHeanc6XWyVO4uHbZR4QQHAk49MFXPAWOZIs4XRybKF4B65eHPEyvNEfDHfLgAw5fUEXK6Q1wePAABXg6AAbnwonhunhSGc1NsgSF0BFgug8Nx0Jk4kEYCtJbphLcXAL+NxhZlsuxZchsPofABGCy6KB4HwAJlN11xrgMxvyTTMeAAAq6LZanS8zBDqJUuC19MxmPY+RkSoEAI54ADeeikeoN3SgGXsAF9KszfN0Glw8IgIN14tgQDRA7ySgYANoAXT9FYjDj0+jrfvLQNWITOtQgABVCZHsFH490QxlM9RmfVi3LVkFpYhgOK4tZ9fix8w03hxpLQkEMog+MuVObVPEQi1kOgVvyiM1uj48BF0NhiteWt1ODedyl/dQK3gN8lxgI0SmrFZuxgXsBxsABubo4IyWsOxaICIBAy1wNiIwIgAQi7Ht+0JBCkJQ/9MFUZowHwAAiABBYobAsABSejaLwdCQKNGhKPGGi8Fo+pGjUdY8Bw5cMm6BI8DYjiuOAGBLSAA=== )

T-Gro avatar Jun 09 '25 09:06 T-Gro