InlinedVector doesn't protect against method arguments aliasing the vector about abseil-cpp

[JonathanDCohen]

I'll take a look at the aliasing issues.

For exception safety, the short story is that we know InlinedVector isn't exception safe. I'm currently writing tooling for us to thoroughly test our classes for exception safety. Once we have that, we will start updating all of our types which need to worry about exceptions accordingly.

I would guess that InlinedVector will have slightly weaker guarantees than std::vector, partly for the reasons you outlined. Our current thought is that we will be going for basic exception safety everywhere, and strong exception safety where reasonable and where it won't affect performance.

[JonathanDCohen]

The two-iterator insert, we won't support aliasing, just like in std::vector (#4 in http://en.cppreference.com/w/cpp/container/vector/insert).

The iterator-count overload is also being fixed, yes :)

[JonathanDCohen]

I took a look at this today. Insert() indeed has a bug, and it is fixed in an internal change which will be upstreamed once accepted. Similarly with operator=.

I don't see the issue with push_back. push_back calls emplace_back, which if we need to grow, calls GrowAndEmplaceBack. GrowAndEmplaceBack first allocates a new buffer, then constructs the new object into it, then moves everything else into the new buffer, so it should be safe.

[stephan-tolksdorf]

You're right, I was mistaken about push_back, sorry.

The insert(const_iterator position, size_type n, const value_type& v) and insert(const_iterator position, InputIterator first, InputIterator last) (for forward iterators) overloads also suffer from this issue, but you've probably seen that too. Making the latter completely safe would hurt performance, but maybe an assert that checks e.g. the address of the first element in the range would be worth the overhead.

[JonathanDCohen]

This is fixed in 5fcbe86