Iterator design review

[Ichthyostega]

Within the Lumiera Support Lib, we defined the »Lumiera Forward Iterator Concept« and built various adapters, decorators and builders based on that. Overall, this turned out as tremendously successful, since is is clear and minimalistic and helps to unify and subsume a lot of individual use cases. And, even more important, it eliminated the need to coin various "data source" interfaces, many of which would probably end up relying on virtual functions unnecessarily.

But the actual adapters and the corresponding extension points tend to be somewhat messy and still not totally aligned with each other. In fact, this iterator concept gave rise to several rather independent code islands -- each with slight differences in the fine points of the semantics

• the original IterAdapter was not much used stand alone, and seems to be best suited for hand written custom containers. It turns out to be quite hard to write the extension points in a correct way, and thus I ended up copying a single reference implementation all over the place
• the RangeIter is a somewhat similar idea to the now emerging STL-Range concept. In itself simple and clean, it produced a lot of convenience functions and ad-hoc adapters, some of which maybe might be better relocated into some central helper library header.
• the IterSource adapter and interface became a cornerstone on various component interfaces, since it allows to strip the generic (templated) types and to offer a conventional virtual method interface instead (with the obvious runtime overhead). As such, this created a compound of interconnected code, some of which overlaps with the adapters to RangeIter. And, after some years, it seems the design of the implementation is not quite alright.
• the itertools became a code ecosystem of their own, all sharing a single technical base class and layered sandwich design structure. Some facilities have been built on top.
• as such, this wouldn't be much of a problem, but as an offspring of the IterExplorer endeavour, there is now a competing yet disjunct other code framework to provide roughly the same feature set (and with slightly different runtime behaviour).
• and last but not least there is the recurring need for recursive evaluations. A first solution was based on the »Monads« from functional programming and overall turned out as disappointment: it leads to messy code at usage site and is too rigid to adapt to changing demands. A second design attempt was based on the pipeline and decorator pattern and turned out prolific and went in widespread use — yet is also problematic at times, since the implementation uses quite complex helper types.
• a related challenge is the »Range TS« from C++20, which addresses very similar problems as our Iterator framework, but is much more limited and low-level. Ideally we should provide a bridge between these, and define a C++20 Concept for our »Lumiera Forward Iterators«

[Ichthyostega]

The first monad based tree exploration scheme has been abandoned now, while the second design (pipeline builder) now completely takes its place.

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin

[Ichthyostega]

---

Last days I made a complete overhaul, basically a rewrite of the »Itertools«.

The new design is oriented towards being inlineable, by avoiding the opaque std::function adapter and rather incorporating the nested functor directly. It is intended to be used on the simple cases, while more elaborate iterator pipelines can be built with IterExplorer