> This is not motivation for changing it, you're still just saying it's
possible.

Did you read the code? Or how it may be motivated other than code examples?

вт, 9 дек. 2025 г. в 13:01, Jonathan Wakely <cxx_at_[hidden]>:

>
>
> On Tue, 9 Dec 2025, 04:19 Nikl Kelbon via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> 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!
>>
>
> This is not motivation for changing it, you're still just saying it's
> possible. That's not a reason to do it.
>
>
>
>> 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
>>
>