On Thu, Jun 27, 2019 at 4:54 AM Tadeus Prastowo <tadeus.prastowo_at_[hidden]>
wrote:

> 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.
>

You know, I think that that might be the assumption that the author of
[container.requirements.general]/12 made as well: that if iterators remain
valid, references must necessarily remain valid as well. And every part of
the standard library follows that rule---there are no examples of functions
that invalidate references. But I'm not sure if there's any logical proof
that not invalidating iterators implies not invalidating references.


>
> > --
> > Brian Bi
>
> --
> Best regards,
> Tadeus
>

-- 
*Brian Bi*