Since C++14 requires value-initialized Forward iterators to compare equal, and subtraction/ordering of RandomAccess iterators is based on equality, this program should run to completion: #define _GLIBCXX_DEBUG #include <cassert> #include <vector> int main() { using I = std::vector<int>::iterator; assert(I{} == I{}); assert(!(I{} != I{})); assert(I{} - I{} == 0); assert(!(I{} < I{})); assert(!(I{} > I{})); assert(I{} <= I{}); assert(I{} >= I{}); } instead of reporting "Error: attempt to compare a singular iterator to a singular iterator." for any of the listed iterator operations.
Confirmed (fixing this would remove the "Partial" support noted at https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2014 :-)
My reading of the N3644 changes is that only equality comparisons are supported, not relational ones.
Or is the implication of equality being valid that a+n is valid for n==0, and therefore b-a is valid, and therefore relational ops are valid?
(In reply to Jonathan Wakely from comment #3) > Or is the implication of equality being valid that a+n is valid for n==0, > and therefore b-a is valid, and therefore relational ops are valid? Certainly b-a is required to be valid, since such an n exists as required by [random.access.iterators] - but admittedly the IS doesn't specify the domain for relational comparisons on Cpp17 iterators. IMO this is a defect since it implies you can *never* compare two iterators with e.g. <. We should require the domain of relational comparisons to be the same as the domain of equality, which would then make it clear that value-initialized iterators are in their domain. (I was under the impression that we *did* require this "somewhere" when I filed this issue and fixed MSFTL's iterators.)
IIRC my reasoning was that [random.access.iterators] specifies the operational semantics of `a < b` to be `b - a > 0`, which suggests but doesn't quite require that `a < b` is valid whenever `b - a` is valid.
After fixing the duplicate PR 98466 std::vector<int>::iterator is ok but std::deque<int>::iterator seems to be broken still. Taking it.
Main issue fixed as part of PR 98466 and 33a1e511b57465d898429740377466894a0b247d fixed the last part for deque::iterator - operator.