D-style (higher-order) (lazy) ranges

[nordlow]

Are there any plans on adding D-style (higher-order) (lazy) ranges to Zig?

Preferrably with compile-time inference of capabilities such as:

• in-place sort algorithms (such as D's sort) require random access ranges via template restrictions (in this case isRandomAccessRange) returning a wrapper range exposing a sortedness property att compile-time.
• range property inference: multi-array in-place sort using: sort(chain(a,b,c, ...)) works because chain(a, b, c) is random access iff a, b and c are all random access.
• and more

[BraedonWooding]

My lazy zig library may be a good starting point :).

[nordlow]

If and when Zig decides to add ranges I suggest digging into Rust's iterators, D's std.range and std.algorithm and Eric Nieblers' corresponding C++-solution range-v3 for inspiration. There are lots of details that have to work in symphony to make higher-order lazy ranges/iterators expressive, easy to use and performant.

Please don't repeat the mistake C++ did with its iterator library for C++98 by making the iterator a generalization of pointers. It's too low-level and too error-prone to use.

I believe Rust's API with a function next returning an optional value is easier to implement and reason about in the compiler than D's empty, front and popFront.

Note, however, that D provide a clever way of exposing the property of infiniteness (generator) of a range; making the function bool empty(); a compile-time constant enum empty = false; which, in turn, is detected by the trait isInfinite. This property needs to be exposed somehow and my proposal is to make next (always) return a value instead of an optional value indicating that a value is always available. Perhaps Rust already has implemented this. I'm not sure.

[andrewrk]

There is no plan for this feature.

However pay attention to the coroutine rewrite (#2377) because it's possible Zig may gain generators out of it.