IterExplorer should be move only

[Ichthyostega]

The monad like framework on top of IterExplorer is a challenge in itself, and it has yet to prove its practicality. It seems like Functional Programming requires a garbage collector in order to fly for real. Otherwise, you'll end up opening the box, and the innards of a Monad tend to be especially gory (which is the very reason why monad is such a powerful concept). Especially in our case here, the requirement from the Lumiera Forward Iterator concept for the iterator itself to be a copyable value object turns out to be the source for much complexities, unexpected overhead and likewise puzzling behaviour.

Is should thus be considered to make IterExplorer move only. Maybe even to be expanded to any derivative of the IterStateWrapper...

Obviously, the task is to conduct an usage analysis first to gauge the impact of this change and to find out the right extend to limitations to expose. While it seems rarely necessary to reassign an existing iterator, the situation is not so clear when it comes to copy initialisation. Since a prohibitive stance here carries over to any object holding an iterator as a member. Is this actually a concern in practice? Can we reap the full benefit of simplified state handling even when allowing copy initialisation?

Questions which require IterExplorer to go into widespread usage before they can be answered

[Ichthyostega]

Questionable.

Meanwhile, I am leaning more and more towards the second design attempt, the TreeExplorer, which is a pipeline builder. The latter could easily superseede IterExplorer alltogether (and would than step into its place, using the more catchy name). However, TreeExplorer is deliberately built to be copyable, and the ability to "fork" an evaluation by copying the complete pipeline with embedded state turns out to be a fundamental trait. Obviously, it could be a liability as well, since it requires the programmer to understand the fine points of state and instance identity.

[Ichthyostega]

...and it turned out as predicted...

• the monad based IterEplorer design was not practical, while the second, pipeline-based design TreeExplorer turned out to be prolific, could be adapted to cover more use cases, and could be improved in performance.
• moreover, due to the builder approach taken for the latter, and the use of a »state-core«, in most cases the solution becomes self-contained and can thus be copied (or moved) as needed.

Today I removed the first solution and renamed the second solution to use the better name IterExplorer

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin