3 ms·
The problem is that zig's designers apparently don't want to introduce an iterator abstraction, hence the frankenstein-ing of the for loop instead. Though in f
by masklinn 4y ago
The problem is that zig's designers apparently don't want to introduce an iterator abstraction, hence the frankenstein-ing of the for loop instead.
Though in fairness getting an iterator abstraction to the same efficiency as a for loop requires pretty brutal optimisations, frankensteining your for loop, a lot less so.
- throwawaymaths 4y agoI don't know how ranges are implemented now (and I'm too lazy to check right now) but It's entirely possible zig's ranges could wind up as comptime-only values. Then you could pass them around, but only at comptime, which will achieve many of the things you expect. There's also nothing stopping you from creating an iterator interface in userland.
- tialaramex 4y ago> There's also nothing stopping you from creating an iterator interface in userland. I don't see any way you could do that with these ranges, and I'm unsure to what extent you can do this for any of the built-in types without their co-operation. If it needs co-operation then there's actually a lot stopping you from creating a useful iterator interface. Also there are a bunch of plausible iterator APIs ranging from a very narrow API like Rust's Iterator trait to something as broad as C++ "iterators" which are effectively just (sometimes magic) pointers.
- matu3ba 4y agoYes, this makes debug builds bloated and slow.
- xigoi 4y ago> Though in fairness getting an iterator abstraction to the same efficiency as a for loop requires pretty brutal optimisations How about Nim's inline iterators?
- cultureswitch 4y ago> Though in fairness getting an iterator abstraction to the same efficiency as a for loop requires pretty brutal optimisations That's the role of the compiler and if Rust or C++ are anything to go by, it is more than capable to "see through" iterators.