std::iterator_traits 中类型别名的“默认值”总是正确的吗？

Question

I've read on cppreference that with C++20, it's possible to omit specifying the type aliases reference , pointer and iterator_category when defining a new iterator. In this case, the corresponding aliases in std::iterator_traits will have "default" values. The details of this are a bit confusing to me, so I'm trying to split this topic into answerable questions. So, my first question is: Are all (or some) of these "default" aliases guaranteed to be correct?

As I understand it, the iterator_category tags are based on the C++17 named requirements. If an iterator satisfies the forward iterator requirement (but not the bidirectional requirement), its tag should be forward_iterator_tag .

I'm specifically worried about the distinction between forward_iterator_tag and input_iterator_tag . Forward iterators have to be able to be used in multipass algorithms, but I don't think the compiler checks that this is the case. Are there cases where I can know that the "default" aliases will be correct (eg an output iterator is always classified correctly, or the default reference alias is always correct)?

Answer 1

Define "correct". The point of having defaults is to cover the most common cases adequately, while still allowing them to be overridden manually when needed. This implies that, in those cases, the defaults wouldn't be appropriate.

Can you write a type where the defaults are not valid? reference is by default whatever *t returns, so it's pretty hard for the default to be wrong even for proxy iterators.

pointer is defined to be what operator-> would yield, but if no such thing exists, it would be void . But that's OK, because the pointer trait isn't really useful since operator-> isn't even required to be supported by any iterator type.

iterator_category 's default is more likely to yield an improper result, but it's not exactly common. Input iterators are less common than other types, so you can easily avoid issues by just specifying the tag when you're writing an input iterator.

It should also be noted that iterator_category specifies conformance to C++17 iterator categories. The C++20 concepts can be overridden by providing an iterator_concept tag specification.

Note also that the ITER_CONCEPT meta-function in C++20 that extracts the iterator tag for the C++20 concepts explicitly bypasses the defaulting mechanism of iterator_category . That is, it only checks the tag you explicitly specify on the iterator itself (either via iterator_concept or iterator_category as a fallback) or on an iterator_traits specialization , not the default that the primary iterator_traits template would produce. So C++20's concepts requires you to specify the tag in some way, despite iterator_traits::iterator_category having a defaulting mechanism.