Ichthyostega 68460d4900 Library: a subtle fix to iterator value-type deduction ...

After some investigation, I seem to understand the problem better now.
This builds upon the Introduction of our `ValueTraits´ two years ago:

e176e54004

The root cause to these ongoing sporadic problems with type deduction
seems to be that we encounter a **clash of concepts**: What Lumiera calls
an »Iterator« is essentially different to the order of terms used by the STL.
In the STL, an iterator can be seen as an ''abstracted pointer'', and is
thus only meaningful in conjunction with a backing container. It is also
this backing STL container that provides the value-type definitions.

In Lumiera however, an ''Iterator is a promise to retrieve a sequence of evaluations''.
For that reason, the Iterator itself provides value-type definitions,
and the notion of "iterable" can largely be conflated with "Lumiera Iterator".

Now, the `lib::RangeIter` can act as a bridge between both usage patterns,
and thus it is possible to create a `RangeIter` both from a Lumiera Iterator
or from a STL container. (As an aside, this is a similar idea as promoted
by the "Range TS" in C++20 -- yet the Lumiera iterator concept is much more
abstract and allows evaluations like tree expansion and search algorithms,
which would be never possible with the STL based notion of iteration)...

Thus the value type binding in `RangeIter` is the only correct place
where to mitigate this ''clash of concepts:''
 * if the `IT` parameter is a Lumiera iterator, we need to retrieve
   the type bindings defined therein
 * otherwise, we can assume that `IT` is an STL iterator and thus
   essentially a pointer, and we must strip that pointer and work from there.

2026-03-25 21:07:26 +01:00

12 MiB

Raw Blame History

The file is too large to be shown.