> The fact that iterators are widely and successfully used in the wild does not > automatically make their implementation satisfactory.
For me it does mean this, esp if you then wander off into insolvable problem spaces. So yeah, inline iterators cannot be recursive. Their name gives it away -- and when you described their nature as > "iterator lite" \- zero cost abstraction, compile time code-substituting and > for-loop inverting like the current inline-iterator it seems to me that they really are "satisfactory", even for you, they fit your description. The fact that the JS codegen doesn't support closure iterators might make the JS codegen "work in progress", not closure iterators. Closure iterators are the foundation for Nim's async. Would they be better if they allowed for recursion? Sure. Is their design "satisfactory"? Well maybe not -- but they are used for async. The criteria that you picked for calling closure iterators "satisfactory" might themselves not be satisfactory. > My main point is that the RFC <https://github.com/nim-lang/RFCs/issues/232> > makes possible to pass inline-iterators around but it does not seem to > address the case of recursive iterators. That doesn't concern me much -- once they support recursion you would complain that they are still not (un)delimited continuations. ;-)
