Date: Sun, 3 Nov 2019 18:35:06 -0500
I have a library that provides, among other things, ranges of integer
values. The range is very useful, with one exception. The iterator type is
stuck on LegacyInputIterator. The reason is that operator* returns
by-value, which is valid because, among other limitations, the type must be
trivially copyable. Other than this fact, it could be a
LegacyRandomAccessIterator (given that indexing or advancing by a
non-single step is O(1)). The only issue is that I can’t move the iterator
type passed LegacyForwardIterator (note that I do not know for certain but
I believe ranges ForwardIterator has this same limit), as
LegacyForwardIterator requires reference to be, in fact, a reference type.
As shown, LegacyForwardIterator having this is a massive roadblock. The
only constraint this type does not satisfy is this single requirement 2
levels up.
This restriction could be relaxed in certain situations.
I propose to relax the limitations as follows;
Given A LegacyForwardIterator type FI, with element_type T:
If, T is trivially copyable, then FI::reference and FI::const_reference may
both be T. Such a LegacyForwardIterator would not be mutable. All other
constraints of LegacyForwardIterator MUST still be satisfied.
values. The range is very useful, with one exception. The iterator type is
stuck on LegacyInputIterator. The reason is that operator* returns
by-value, which is valid because, among other limitations, the type must be
trivially copyable. Other than this fact, it could be a
LegacyRandomAccessIterator (given that indexing or advancing by a
non-single step is O(1)). The only issue is that I can’t move the iterator
type passed LegacyForwardIterator (note that I do not know for certain but
I believe ranges ForwardIterator has this same limit), as
LegacyForwardIterator requires reference to be, in fact, a reference type.
As shown, LegacyForwardIterator having this is a massive roadblock. The
only constraint this type does not satisfy is this single requirement 2
levels up.
This restriction could be relaxed in certain situations.
I propose to relax the limitations as follows;
Given A LegacyForwardIterator type FI, with element_type T:
If, T is trivially copyable, then FI::reference and FI::const_reference may
both be T. Such a LegacyForwardIterator would not be mutable. All other
constraints of LegacyForwardIterator MUST still be satisfied.
Received on 2019-11-03 17:37:34