Make collection iterators fulfill LegacyInputIterator and input_iterator concept

[m-fila]

BEGINRELEASENOTES

• Added missing operations and type aliases so the collection iterators fulfill LegacyInputIterator requirement and std::input_iterator concept, and the collections fulfill std::input_range concept. Thanks to these the collections are compatible with standard algorithms and standard range algorithms such as std::find, std::count, std::all_of

ENDRELEASENOTES

Fixes: #150, fixes #272
Conflicts: #273

Implement missing features so CollectionIterators and MutableCollectionIterators fulfill the requirements imposed on the C++ iterators (#598). It's expected than not all requirements can be fulfilled as some are in direct conflict with podio design:

• LegacyForwardIterator: dereference should return a reference, but in podio iterators are 'proxy iterators' returning user layer objects as a proxy for reference
• LegacyForwardItertor: dereferencing two iterators that are equal should give two references bound to the same object, but in podio the returned 'proxies' are different objects
• std::forward_iterator: pointers and references obtained from an iterator should be valid as range the range is valid, but in podio the iterators behave like 'stashing iterators' -> pointers point to iterator member variable limiting their validity to the lifetime of the iterator.
• LegacyOutputIterator/output_iterator: datatype assignment replaces the internal object handle instead of modifying the handle properties.

As a consequence the iterators can the podio iterators can be at most LegacyInputIterator and std::input_iterator, and collections be std::ranges::input_range. This PR implements missing features to achieve this.

List of changes:

Named requirements:

• LegacyIterator:
  • copy constructor and assignment
  • type aliases
• LegacyInputIterator:
  • postfix increment
• ❌ LegacForwardIterator:
  • value-initialization
  • ❌ dereference return reference not proxy
  • ❌ dereferencing equal iterators returns references to the same object
• ❌ OutputIterator:
  • ❌ assignment should modify collection
• iterator_category is std::input_iterator_tag
• check selected algorithms operating on LegacyInputIterators

Concepts:

• semantics checks for concepts
• std::input_or_output_iterator
  • same as LegacyIterator but copyability not required
• std::input_iterator
  • std::indirectly_readable and std::readable (can dereference both iterator and const iterator)
• ❌ std::forward_iterator
  • syntax: constrains (except iterator_concept to be derived fromstd::forward_iterator_tag)
  • ❌ semantic: pointers obtained from iterator should remain valid as long as range is valid (no-stashing)
• iterator_concept is std::input_iterator_tag
• check range concepts
• check selected range algorithms constrained to std::input_iterator

[tmadlener]

I know this is not fully done yet, but I think it would be nice to also document which (classes of) algorithms will be enabled by this (if any).

[Zehvogel]

can you also take a look at podio::RelationRange? :)

[m-fila]

Thanks for pointing out, I'll check it out later

[tmadlener]

Stupid question:

LegacyForwardItertor: dereferencing two iterators that are equal should give two references bound to the same object, but in podio the returned 'proxies' are different objects

What are the semantic requirements for this? operator== returns true when comparing them? Or do they literally have to be a reference to the same object, i.e. the address of the referenced object has to be the same?

If the former is the case, than this should be doable, I think. Because our operator== compares the handled Obj.

[m-fila]

What are the semantic requirements for this? operator== returns true when comparing them? Or do they literally have to be a reference to the same object, i.e. the address of the referenced object has to be the same?

If the former is the case, than this should be doable, I think. Because our operator== compares the handled Obj.

Unfortunately it's the second. One of the previous points already states that *it must be a reference (as in & or &&), then

If i and j are both dereferenceable, then i == j if and only if *i and *j are bound to the same object.

---

I think this is ready.
We can have LegacyInputIterator and std::input_iterator without big changes.

• LegacyForwardIterator seems to be fundamentally not compatible with the semantics we have,
• LegacyOutputIterator and std::output_iterator would require to change the nature of assignment in datatypes - which is a big change that I don't really want to force here.
• std::forward_iterator is almost there. If this gets merged then I could separate discussion whether we can get it with some disclaimers.

[tmadlener]

Thanks a lot for all the work. I mainly have a few minor questions, resp. some (hopefully small) requests for some potential re-organization.

[tmadlener]

This looks like we should consider adding mutable_type directly to the collection as well (I don't think we have yet)?

[m-fila]

We have it in link collections but not in the datatype collections. I guess then we should also think if there should be one in user data collection to keep the api somehow similar.

But I think this could be done in a separate PR as it's not touching our compliance to iterator specification

[tmadlener]

Yes, definitely a separate PR.