Open in StackBlitz

npm i https://pkg.pr.new/rescript@7887

npm i https://pkg.pr.new/@rescript/darwin-arm64@7887

npm i https://pkg.pr.new/@rescript/darwin-x64@7887

npm i https://pkg.pr.new/@rescript/linux-arm64@7887

npm i https://pkg.pr.new/@rescript/linux-x64@7887

npm i https://pkg.pr.new/@rescript/runtime@7887

npm i https://pkg.pr.new/@rescript/win32-x64@7887

commit: ee5708e

The big questions were language design related ones, rather than implementation.
There are many ways to go about this.
@cometkim still got some design notes from the retreat? This could be the right time to do some more text-based discussion before the code-based one.

Frankly, importing the JavaScript for-of syntax as-is doesn't sound all that appealing. It's not much different from embedding %raw.

Here are my thoughts on designing for loops:

1. Since iterators are essential in JavaScript, we need to define iterator semantics before design the synyax. The syntax follows.
2. Without control flow support, the for-of syntax itself isn't very useful. With good control semantics, the simple iterator protocol and even the MoonBit style loop syntax become useful.
3. The current for x into y syntax is valid for index-based access, but the JS' for-of doesn't. To combine the benefits of both style, generator (for sequencing) support will be needed. Zig's for loop design is a good example.
4. Are for statements enough? To maintain a robust type-based approach, it would be better to design them based on expressions.

@cometkim still got some design notes from the retreat?

https://github.com/JonoPrest/iterator-rescript/blob/retreat-note/RETREAT_NOTE.md

On the last retreat, we only discussed iterator semantics and simulating break/continue; we also need to deal with the early-return or jump (for escaping nested loops) semantics.

Early return keeps on coming up as a topic.
Perhaps it makes sense to explore that as a prerequisite to this.

For me, the for..of feature as implemented here would already be useful in and of itself because it

1. allows the usage of await like in this example from the tests which would not be possible using arr->Array.forEach(...)

let asyncProcess = async () => {
  let results = []
  for item of arr {
    let result = await processData(item)
    results->Array.push(result)
  }
  results
}

2. is more concise

for item for arr {
# vs.
arr->Array.forEach(item =>

3. is more performant

4. Increases our coverage of JS features that JS developer may expect to have

I agree that early return would be nice to have, but not sure if we should tie this to for..of.

I also agree that it would be a good idea to look into how iterators should work.
OTOH having this for arrays would be a low-hanging fruit that could hopefully be extended to iterators later.

OTOH having this for arrays would be a low-hanging fruit that could hopefully be extended to iterators later.

This is already a dangerous assumption. for-of loops are all about iterators, not arrays.

It should be designed to interact with iterator types. When it works with array types, it leads users to copy arbitrary iterators into arrays unnecessarily.

@codex review

It should be designed to interact with iterator types. When it works with array types, it leads users to copy arbitrary iterators into arrays unnecessarily.

Done! 😄

@codex review

@codex review

Codex Review: Didn't find any major issues. Bravo.

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".