you wrote bug while trying to avoid useless and incorrect standard wording,
thats why it must be changed

вт, 9 дек. 2025 г. в 14:29, Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]>:

> Isn't it enough, if the for loop checks for the last element instead of
> one beyond?
>
>
>
> This would work with all containers with bidirectional iterators. For
> forward_list there is not even a push_back() function.
>
>
>
>
>
> #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) {
>
>
>
> --e; // INSERT
>
>
> 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);
> }
>
>
>
> vec.push_back(*b); // INSERT
>
>
> }
>
> 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());
> }
>
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Nikl Kelbon via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Di 09.12.2025 05:19
> *Betreff:* Re: [std-proposals] vector::push_back must not invalidate
> past-the-end iterator
> *An:* std-proposals_at_[hidden];
> *CC:* Nikl Kelbon <kelbonage_at_[hidden]>;
> 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>