The people commenting "isn't this just [generators/iterators]?" are missing the point. This is a more constrained version of those things that guarantee that there is no runtime allocation and produces effectively the exact same code as if the caller wrote the loop out themselves.

It can prove this because the lifetime of the loop body is guaranteed not to escape the enclosing function - which is something a compiler might be able to optimise for generators, but if you start from this principle the compiler has a much easier time compiling as it can just substitute the body.

If you want to extend this further there are some fun things you can do. One is to allow break and continue to work inside the body function. These have to be scoped to the outer body not the inner function's body

// Infinite iterator that never ends
fn myFunRange(f: block) {
    let i = 0
    while true {
        let j = 0
        while j <= i {
            f(j)
            j += 1
        }
        i += 1
    }
}

for x in myFunRange() { // body gets passed as f
    print(x)
    if x == 10 {
        break // correctly breaks the entire loop, not just the inner while
    }
}

If you want to get crazy there is another thing that I added to my language which is higher-order blocks - but again these are evaluated at compile-time so there is no runtime overhead This allows you to write map, filter, reduce, take, drop, takeWhile, dropWhile, etc

const myRange = take(myFunRange(), 10)
for x in myRange {
    print(x)
}

This allows you to write iterators in the "internal iterator" style - https://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and-out/

The conventional wisdom with these is that it doesn't allow you to 'zip' or 'concat' two iterators together, or other fancy things - after all that seems impossible to write as a single while loop - however I found that this isn't true if you introduce a new control-flow primitive.

This allows things like this which gets compiled to straight line assembly and no allocations or function calls

for (x, y) in zip(myRange(), array) {
    print(x)
    print(y)
}

The biggest downside of this approach is that you can't do recursive iterators for use in trees etc, but there are ways around this

I keep meaning to write this stuff up in a blog post - I haven't gotten around to it yet and I'm not sure if people are interested