Consider turning ITER_CONCEPT into an associated trait
cjdb opened this issue · comments
iter_concept_t would be a useful type for writing custom iterator and range adaptors, and should probably be present from the beginning.
Ack, no! There is a reason ITER_CONCEPT is left as an implementation detail. It defaults to std::random_access_iterator_tag, which is wrong for the majority of iterators. It is only useful as an implementation detail of the iterator concepts.
When would it be handy to know the iterator tag instead of using the concepts?
It defaults to std::random_access_iterator_tag, which is wrong for the majority of iterators. It is only useful as an implementation detail of the iterator concepts.
Yep, fair enough there (I wasn't aware of this). Perhaps adding an associated trait that behaves as-if it were the bottom example in that case?
When would it be handy to know the iterator tag instead of using the concepts?
I primarily want this to simplify iterators that are embedded in range adaptors. Writing something a la
using iterator_concept = std::conditional_t<ranges::random_access_range,
random_access_iterator_tag,
std::iter_concept_t<std::iterator_t<R>>>;
// not sold on range_concept_t being an alias for iter_concept_t<iterator_t<T>>is much nicer than needing to write them all out by hand (I'd write my own iter_concept_t in that case).
using iterator_concept = // ick, for many reasons
std::conditional_t<ranges::random_access_range, std::random_access_iterator_tag,
std::conditional_t<ranges::bidirectional_range, std::bidirectional_iterator_tag,
std::conditional_t<ranges::forward_range, std::forward_iterator_tag,
std::conditional_t<ranges::input_iterator_tag, std::input_iterator_tag>>>>;Is there an existing trait I've overlooked?
Is there an existing trait I've overlooked?
No. I would probably implement the trait as a function with cascading if constexpr (foo_iterator<I>) tests that returned the tag type, wrapped in a decltype. Might be a worthy addition, but also not worth holding up C++20.