@SamWhitlock
51:00 sometimes I get the feeling that views, though useful, still force one to mentally "unroll" the abstraction to raw underlying iterators. I still am glad they're in the language (despite the issues Nico pointed out in his talk), but they really aren't as ergonomic as other languages that are supported by a runtime :(
@NoNameAtAll2
so, to summarize
- input iterators (one pass/generate on demand ones) need to cache element it's gonna output/it's pointing to
- range operations leave iterators in "one past last used element" state (".end()")
input iterators pretty much "read past the last element"?
take(5) example shows that ".end()" value gets consumed into cache, but not returned in any way
iota-filter shows example where "reading .end()" results in endless loop
std::istream family deal with that via failure flags, because "file/string ran out" is easy to detect
but iota-filter can't do that
@27182818284590452354
So much effort is spent on trying to fit a square piece into a circular hole. Why don't we just agree that a pair of STL iterators is not a proper interface for some tasks of set traversal? Since we end up with even more ways to do the same, shouldn't we make the new way not only sensible in itself, but purposefully distinct to avoid confusion?
@HuyNguyen-fq4rh
Is his code better than a G-code parser?
@Messmerd97
Stuff like this makes me question the value of range pipelines. They look simple and cool and all, but they bring so much unintuitive behavior that it seems you need a strong understanding of their implementation details before you can use them correctly and efficiently. At that point, why bother?
@simonfarre4907
The simplicity of Rust's iterators and views are looking more and more appealing.
@russCoding