On Wed, Jun 26, 2019 at 11:45 PM Brian Bi <bbi5291_at_[hidden]> wrote:
>
> On Wed, Jun 26, 2019 at 4:35 PM Tadeus Prastowo <tadeus.prastowo_at_[hidden]> wrote:
>>
>> On Wed, Jun 26, 2019 at 11:00 PM Brian Bi <bbi5291_at_[hidden]> wrote:
>> >
>> > http://eel.is/c++draft/container.requirements.general#12
>> >
>> >> Unless otherwise specified (either explicitly or by defining a function in terms of other functions), invoking a container member function or passing a container as an argument to a library function shall not invalidate iterators to, or change the values of, objects within that container.
>>
>> Thank you very much for pointing that out. Any idea why that passage
>> mentions only the word "iterator" but not "reference"?
>
>
> I don't know. Maybe it's just an oversight, maybe they thought it was obvious. I am also curious about the answer now.

If I look at its sibling, the container list, the requirement is
spelled out clearly for push_front. To quote
http://eel.is/c++draft/list.modifiers#1: Remarks: Does not affect the
validity of iterators and references.

So, I think, the standard should be fair to do the same for
forward_list, all the more that it says something for insert_after but
nothing for push_front. How to raise this issue so that the committee
will consider to write the iterator-and-reference non-invalidation
requirement for forward_list's push_front?

>> > I suppose that the first sentence of [sequence.forwardlist.modifiers]/1 is redundant.
>>
>> Yes, unless the words "reference" and "iterator" imply different things.
>
>
> Good point... they do imply different things. But I would be surprised if there isn't also an (implied) general requirement for container member functions to not invalidate references unless the standard specifies otherwise.

Would you mind telling me how they imply different things because my
current understanding, which likely is wrong, is that "iterator"
implies the use of "reference" but not vice versa so that not
invalidating "iterator" implies not invalidating "reference" but not
invalidating "reference" still allows "iterator" to be invalidated?

Thank you very much.

> --
> Brian Bi

-- 
Best regards,
Tadeus