Support more types in for-loops

[brianrourkeboll]

Description

• Support more types in for-loops, a.k.a. "simple for-loop expressions" (§ 6.5.7 of the F# language spec) or "indexed for-loops."
  • Language suggestion: Allow for int64 and bigints in indexed for loops fsharp/fslang-suggestions#876
  • RFC: TODO
  • RFC discussion: TODO

Examples

// = for n in 1uy..10uy do ()
for n = 1uy to 10uy do ()

// = for n in 1L..10L do ()
for n = 1L to 10L do ()

// = for n in 10L .. -1L .. 1L do ()
for n = 10L downto 1L do ()

// = for n in 1I..10I do ()
// Note however that we still do not have optimizations for bigints in either syntax.
for n = 1I to 10I do ()

Checklist

• Test cases added.
• Release notes entry updated.

[github-actions]

❗ 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.300.md

[T-Gro]

Since this does affect the language, the new fallback branch should be guarded with a LanguageFeature flag.

This will also need same extension of the https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/loops-for-to-expression section of the docs (the "docs diff" can also be used as an RFC).

Will there be limitations for downto and unsigned numbers?

[auduchinok]

Since this does affect the language, the new fallback branch should be guarded with a LanguageFeature flag.

It can also be a branch producing a recoverable error like "F# 10/preview is required". It would allow having a single branch in the checking logic, while also fail the build, effectively disallowing the new behavior in the older language versions.

[T-Gro]

Since this does affect the language, the new fallback branch should be guarded with a LanguageFeature flag.

It can also be a branch producing a recoverable error like "F# 10/preview is required". It would allow having a single branch in the checking logic, while also fail the build, effectively disallowing the new behavior in the older language versions.

Indeed, checkLanguageFeatureAndRecover looks optimal here

[brianrourkeboll]

Since this does affect the language, the new fallback branch should be guarded with a LanguageFeature flag.

Agreed.

This will also need same extension of the https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/loops-for-to-expression section of the docs (the "docs diff" can also be used as an RFC).

Agreed.

Will there be limitations for downto and unsigned numbers?

Yeah. As-is, downto wouldn't work with unsigned numbers. That would require some new codegen—which, however, we could always add later.

[T-Gro]

What will the user experience when using downto to unsigned integral types? Is the message and range for it after this PR good enough?

(existing integral for .. to .. loop just emits the generic FS0001, so the bar is low here)

[brianrourkeboll]

What will the user experience when using downto to unsigned integral types? Is the message and range for it after this PR good enough?

(existing integral for .. to .. loop just emits the generic FS0001, so the bar is low here)

It will tell the user that the type does not support the unary minus operator ~-, i.e., the same error they would get if they had written start .. -1u𝑥 .. finish themselves.

That is probably not ideal, since the user wrote start downto finish and not start .. -1u𝑥 .. finish.

If we wanted to emit an error more like "downto is not supported for unsigned numeric types," we'd need to do something like keep track of the fact that the AST originally had downto through to the point in time when we typecheck the synthetic range expression with the negative step and it fails.