Just to correct a few things after peaking at cppreference. I thought that
iterators had const_reference like collections did. Apparently I was wrong,
so disregard mentions of const_reference. And when I used FI::<type> I did,
in fact, mean std::iterator_traits<FI>::<type>.

On Sun, Nov 3, 2019 at 6:35 PM connor horman <chorman64_at_[hidden]> wrote:

> 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.
>
>