Open in StackBlitz

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

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

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

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

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

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

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

commit:8b779af

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 styleloop syntax become useful.
3. The currentfor 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 ofawait like in this example from the tests which would not be possible usingarr->Array.forEach(...)

letasyncProcess=async ()=> {letresults= []foritemofarr {letresult=awaitprocessData(item)results->Array.push(result)  }results}

2. is more concise

foritemforarr {#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.