Changeset 68460d4 in Lumiera

Timestamp:

2026-03-25T20:07:26Z (4 weeks ago)

Author:

Ichthyostega <prg@…>

Branches:

dev/play

Children:

fbda9ba

Parents:

bf77e53

Message:

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:

e176e540043177

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.

(No files)