Iterators and Ranges: Comparing C++ to D to Rust

[Petar]

On Tuesday, 15 June 2021 at 07:22:24 UTC, Araq wrote:
> On Monday, 14 June 2021 at 23:08:40 UTC, Ola Fosheim Grøstad 
> wrote:
>> On Monday, 14 June 2021 at 22:56:29 UTC, IGotD- wrote:
>>> How do we classify the iterators of Nim?
>>>
>>> https://nim-lang.org/docs/tut1.html#iterators
>>>
>>> It looks similar to Python and Rust. Also notice how it can 
>>> use yield like a coroutine.
>>
>> Yes, but the page says that they have to be inlined and used 
>> in for-loops only? But if they are made more general then they 
>> would be generator coroutines like Python and C++.
>
> There is also a variant called "closure" iterators which is 
> Nim's foundation for async programming. Nim's inline iterators 
> don't compose particularly well, but they get the job done and 
> there are all sorts of workarounds and 3rd party packages.

In addition to Nim's inline and closure iterators, which if I 
understand correctly, model input iteration (not sure about 
forward), is there an at least somewhat standardized interface 
for implementing iterators manually that does support backward 
iteration and random access? What do the most prominent Nim 
libraries do?

One of the things that I don't like about languages that I use 
that have built-in iterators like C# and JavaScript/TypeScript is 
that pretty much their whole ecosystems only cares about input 
iteration and things that in D are trivially `O(1)` like 
`array.map!foo[$/2 .. $].retro.map!bar.length` end up being 
unexpected performance pitfalls in practice in these languages.

> We couldn't copy C++ or D's designs because they are 
> fundamentally unsafe (iterator invalidation is complex and 
> expensive). Rust can do it easily thanks to its borrow checker.

Heh, when I guess many people having read the the infamous 
"fearless concurrency" blog post believe that iterator 
invalidation is a big deal and that languages really ought to 
prevent it statically and now demand it from language maintainers 
(which is a good thing™). That said, no matter how easy is to 
show that innocent looking code can end up with an iterator 
invalidation bug, in practice I don't remember ever experiencing 
it in my D code. Resisting the urge to mutate a container while 
you're iterating is really not that hard :D Perhaps iterator 
invalidation problems are more common with imperative-style raw 
loops code, rather that FP-style, which I feel is much better 
supported by D's standard library, than the standard libraries of 
other languages like C++, C# and JS.

That is not to say that I wouldn't want my libraries to be 
fool-proof against that kind of problems, but at same time, at 
least in my experience with D it hasn't been a big deal, so I'd 
much rather have a powerful algorithmic API foundation than 
prevent very useful and beautiful designs, just because they can 
be misused.

> We're slowly catching up with our support for "view types".

Interesting, can you elaborate more?