Yes, the arguments must be immutable even after the for in that case.
Seems like the syntax is this:
iterator foo[T](s: seq[T]{call,`let`}): T =
var i = 0
while i < s.len:
yield s[i]
inc i
That's an interesting approach, and it would be sufficient in some cases.
Thanks.
@mratsim: Could you elaborate on the third option, please? The following
doesn't compile:
iterator foo[T](s: seq{call,`let`}[T]): T =
var i = 0
while i < s.len:
yield s[i]
inc i
Whatever the correct syntax is, wouldn't this restrict potential
Some ideas from the future Nim
1\. Writetracking:
[https://nim-lang.org/araq/writetracking.html](https://nim-lang.org/araq/writetracking.html)
2\. Iterator returns a lent type so that mutation is a compile-time error:
Cool. Thanks for putting some thought into this
I suppose that unrestricted referencing is one of Nim's design decisions in the
language as a whole as well. It is perfectly valid to hold multiple mutable
references to one object. Data can change under your feet at any time with this
setup, so
Thanks! I hadn't thought of the effect system hmmm
> Should I/can I ever count on an iterator in Nim to handle the structure being
> changed during iteration?
Not unless the implementation promises to handle it, I suppose. There's nothing
implicit in an iterator that stops it from being affected by changes in the
structure. e.g.
Hello,
I have a conceptual/style question here.
In C++ (and presumably some other languages), there is a concept called
"iterator invalidation". The basic idea is that while iterating a structure,
changes to the structure could break iteration, leading to a loss of memory
safety.
