https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> --- Yes, I'm well aware what the standard says, I reported https://wg21.link/lwg2674 I consider it a mistake for the standard to say "these are bidirectional iterators, except they're not, but it's OK because at some point in the future a subset of algorithms won't care about that requirement any more". GCC's implementation provides real bidirectional iterators that meet the C++17 requirements and the C++2a BidirectionalIterator requirement that: "Pointers and references obtained from a forward iterator into a range [i, s) shall remain valid while [i, s) continues to denote a range." The libc++ implementation also fails this test: https://wandbox.org/permlink/RwiFphMn1Hh2iis4 It's OK though, because you don't pay for what you don't use! The design trade off was discussed in Bug 71044 comment 6. Populating the range lazily would still be possible (as long as it was thread-safe) but I'm not convinced it would be an improvement. In theory the range could also be shared by copies of the same path (again, as long as it was thread-safe). Those optimizations can be considered later, but for now the implementation aims to be correct and not produce dangling pointers. As I said, I'll reduce the number of allocations done by the GCC 8.x implementation, but I'm not planning on any other changes for now.
