Im glad you now asking for a motivation and not asking "what is past the
end iterator" or smth what was discussed before

In real code i created my container template, so its iterator combines
several iterators of its parts. std::vector was one of those parts

Then i wrote append(iterator, iterator) and my code sures it is completely
right, no reallocation etc etc.

But msvc stl implementation find a way to assert it (by storing all .end()
iterators in global map under mutex and invalidate them on each push_back)

I dont know any other way to code it. Its impossible. THERE ARE NO OTHER
WAY!

Code:


#include <vector>

struct mytype {
  std::vector<int> vec;

  // in real code it is complex iterator
  // where vector iterator only part of it
  using iterator = std::vector<int>::iterator;

  void append(iterator b, iterator e) {
    for (; b != e; ++b) { // ASSERTION FAILURE, COMPARING b and e after
push_back
      // again, in real code it complex operation with inserting in my
container
      vec.push_back(*b);
    }
  }

  iterator begin() {
    return vec.begin();
  }
  iterator end() {
    return vec.end();
  }
};

int main() {
    mytype x;
    x.vec = {1, 2, 3, 4};
    x.vec.reserve(100);
    x.append(x.begin(), x.end());
}

https://godbolt.org/z/cjfT9vran

вт, 9 дек. 2025 г. в 07:18, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]>:

> On Mon, Dec 8, 2025 at 1:56 PM Nikl Kelbon via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Thats what standard exists for. Standard decides what is ub and what is
> not ub. How its even may be argument "its ub" in discussion about changing
> standard?
>
> Because your reasoning for why this change is needed is that many
> users do it regardless of the fact that it's UB, so it makes sense to
> change it. That is, your proposal is predicated on the idea that this
> is common code, and therefore if it isn't common code, then it has no
> motivation.
>
> So, what evidence can you provide that people believe that end
> iterators should work this way? The fact that it can be implemented is
> not, by itself, sufficient justification for changing the standard.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>