Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC FS-1033: Deprecate places where seq can be omitted #17772

Open
wants to merge 17 commits into
base: main
Choose a base branch
from

Conversation

edgarfgp
Copy link
Contributor

@edgarfgp edgarfgp commented Sep 20, 2024

Description

Implements fsharp/fslang-suggestions#1033

Deprecate { start..finish } and { start..step..finish }

Before

To create a sequence, you can use { start..finish } or { start..finish..step }.

{ 1..10 }

{ 1..5..10 }

[| { 1..10 } |]

[| { 1..5..10 } |]

[| yield { 1..10 } |]

[ { 1..10 } ]

[ { 1..10..10 } ]

[ yield { 1..10 } ]

[ yield { 1..10..20 } ]

ResizeArray({ 1..10 })

ResizeArray({ 1..10..20 })

[ for x in { start..finish } -> x ]

[| for x in { start..finish } -> x |]

for x in { 1..10 }  do ()

for x in { 1..5..10 } do ()

set { 1..6 }

Seq.length { 1..8 }

Seq.map3 funcInt { 1..8 } { 2..9 } { 3..10 }

Seq.splitInto 4 { 1..5 } |> verify { 1.. 10 }

seq [ {1..4}; {5..7}; {8..10} ]

Seq.allPairs { 1..7 } Seq.empty

Seq.allPairs Seq.empty { 1..7 }

[| yield! {1..100}
   yield! {1..100} |]

After

A new warning will be raised when using { start..finish } or { start..finish..step } to create a sequence.

{ 1..10 } // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

{ 1..5..10 } // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

[| { 1..10 } |] // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

[| { 1..5..10 } |] // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

[| yield { 1..10 } |] // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

[ { 1..10 } ] // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

[ { 1..10..10 } ] // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

[ yield { 1..10 } ] // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

[ yield { 1..10..20 } ] // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

ResizeArray({ 1..10 }) // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

ResizeArray({ 1..10..20 }) // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

[ for x in { start..finish } -> x ] // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

[| for x in { start..finish } -> x |] // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

for x in { 1..10 }  do () // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

for x in { 1..5..10 } do () // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

set { 1..6 } // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

Seq.length { 1..8 } // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

Seq.map3 funcInt { 1..8 } { 2..9 } { 3..10 } // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

Seq.splitInto 4 { 1..5 } |> verify { 1.. 10 } // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

seq [ {1..4}; {5..7}; {8..10} ] // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

Seq.allPairs { 1..7 } Seq.empty // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

Seq.allPairs Seq.empty { 1..7 } // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

[| yield! {1..100} // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"
   yield! {1..100} |] // FS3873, "This construct is deprecated. Sequence expressions should be of the form seq {...}"

To create a sequence, you need to use seq { start..finish } or seq { start..finish..step }.

seq { 1..10 }

seq { 1..5..10 }

[| seq { 1..10 } |]

[| seq { 1..5..10 } |]

[| yield seq { 1..10 } |]

[ seq { 1..10 } ]

[ seq { 1..10..10 } ]

[ yield seq { 1..10 } ]

[ yield seq { 1..10..20 } ]

ResizeArray(seq { 1..10 })

ResizeArray(seq { 1..10..20 })

[ for x in seq { start..finish } -> x ]

[| for x in seq { start..finish } -> x |]

for x in seq { 1..10 }  do ()

for x in seq { 1..5..10 } do ()

set { 1..6 }

Seq.length (seq { 1..8 })

Seq.map3 funcInt (seq { 1..8 }) (seq { 2..9 }) (seq { 3..10 })

Seq.splitInto 4 (seq { 1..5 }) |> verify (seq { 1.. 10 })

seq [ seq {1..4}; seq {5..7}; seq {8..10} ]

Seq.allPairs (seq { 1..7 }) Seq.empty

Seq.allPairs Seq.empty (seq { 1..7 })

[| yield! seq {1..100}
   yield! seq {1..100} |]

Checklist

Copy link
Contributor

github-actions bot commented Sep 20, 2024

❗ Release notes required


✅ Found changes and release notes in following paths:

Change path Release notes path Description
src/Compiler docs/release-notes/.FSharp.Compiler.Service/9.0.200.md
LanguageFeatures.fsi docs/release-notes/.Language/preview.md

@edgarfgp edgarfgp changed the title Treat { 1..10 } as sequence expression Treat { 1;10 } as sequence expression Sep 20, 2024
@edgarfgp edgarfgp force-pushed the improve-sequence-expr-inference branch from 59c5208 to d643cfb Compare September 20, 2024 21:30
@vzarytovskii
Copy link
Member

I am not 100% sure what exactly was approved in the comment, but I don't immediately see it as "let's allow omitting seq for those cases everywhere. It is taking about when we pass it to collections.

@edgarfgp
Copy link
Contributor Author

I am not 100% sure what exactly was approved in the comment, but I don't immediately see it as "let's allow omitting seq for those cases everywhere. It is taking about when we pass it to collections.

@vzarytovskii what I understood from Don’s comment was that we want to enforce the seq in places where we pass it to collections via a warning or informational warning.

To do this we need to have valid code for { 1;10} to show such a warning right(We do not show warnings on invalid code AFIK) ?

Also note that { 1..10 } is currently valid currently. So { 1;10} arguable should also be.

To summarise my current approach is:

  • Make {1;10} valid code for consistency
  • Add a warning to force the use of seq when passing it to collections.

@vzarytovskii
Copy link
Member

I am not 100% sure what exactly was approved in the comment, but I don't immediately see it as "let's allow omitting seq for those cases everywhere. It is taking about when we pass it to collections.

@vzarytovskii what I understood from Don’s comment was that we want to enforce the seq in places where we pass it to collections via a warning or informational warning.

To do this we need to have valid code for { 1;10} to show such a warning right(We do not show warnings on invalid code AFIK) ?

Also note that { 1..10 } is currently valid currently. So { 1;10} arguable should also be.

To summarise my current approach is:

  • Make {1;10} valid code for consistency

  • Add a warning to force the use of seq when passing it to collections.

Hm, I've read it a bit differently -

That is, if the seq is being immediately consumed eagerly into a collection construction then I'm happy to omit it.

I read it as - when we immediately pass it to collections, then we do not require "seq" (even for now illegal constructs), otherwise (if not passed to collections) we add a warning enforcing (suggesting really) to add "seq" to "{ x .. y }".

But I have problems decoding the comment w.r.t. allowing other constructs to omit "seq" when not passed to collections (when returning or binding for example.

@edgarfgp
Copy link
Contributor Author

edgarfgp commented Sep 21, 2024

But I have problems decoding the comment w.r.t. allowing other constructs to omit "seq" when not passed to collections (when returning or binding for example.

what about let x = { 1..10 } should this now be disallowed by a warning. I’m trying to understand the rationale about the existing inconsistency between both cases in bindings ?

@vzarytovskii
Copy link
Member

But I have problems decoding the comment w.r.t. allowing other constructs to omit "seq" when not passed to collections (when returning or binding for example.

what about let x = { 1..10 } should this now be disallowed by a warning. I’m trying to understand the rationale about the existing inconsistency between both cases in bindings ?

That's what I understood. Show a diagnostic suggesting adding "seq" if it's not passed to collection. And allow other constructs only when passed to collections.

I'd wait for other folks to read it through, I might be misunderstanding things.

@edgarfgp edgarfgp changed the title Treat { 1;10 } as sequence expression deprecate { start..finish } and { start;finish } using a warning Sep 21, 2024
@edgarfgp edgarfgp changed the title deprecate { start..finish } and { start;finish } using a warning deprecate { start..finish } { start..step..finish } Sep 21, 2024
@edgarfgp edgarfgp force-pushed the improve-sequence-expr-inference branch 2 times, most recently from c05956b to 9c05432 Compare September 22, 2024 12:40
@edgarfgp edgarfgp force-pushed the improve-sequence-expr-inference branch from 9c05432 to 47b4ef0 Compare September 22, 2024 13:06
@edgarfgp edgarfgp changed the title deprecate { start..finish } { start..step..finish } RFC FS-1033: Deprecate places where seq can be omitted Sep 22, 2024
@edgarfgp edgarfgp force-pushed the improve-sequence-expr-inference branch from 4fc0837 to de89b44 Compare September 28, 2024 15:43
@edgarfgp edgarfgp marked this pull request as ready for review October 4, 2024 19:48
@edgarfgp edgarfgp requested a review from a team as a code owner October 4, 2024 19:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: New
Development

Successfully merging this pull request may close these issues.

2 participants