[vector.capacity] p14 The precondition use "and" but should use "or"

[xmh0511]

[vector.capacity] p14 says

constexpr void resize(size_type sz);

Preconditions: T is Cpp17MoveInsertable and Cpp17DefaultInsertable into *this.

Cpp17MoveInsertable is defined in [containers.container.alloc.reqmts] p2.3

T is Cpp17MoveInsertable into X means that the following expression is well-formed:

• allocator_traits::construct(m, p, RV)

[containers.container.alloc.reqmts] p2 says

given an lvalue m of type A, a pointer p of type T*, an expression v of type (possibly const) T, and an rvalue rv of type T,

Consider this example:

struct A{
   A() = default;
   A(A const&) = default;
   A(A&&) = delete;
};
int main(){
   std::vector<A> vec{};
   vec.resize(10); // ok
}

However, A is not Cpp17MoveInsertable since allocator_traits<A>::construct(m, p, RV) is ill-formed for A.

[JohelEGP]

I think it's "and" because when sz > capacity(), the first size() elements use Cpp17MoveInsertable and the rest Cpp17DefaultInsertable.

[xmh0511]

I think it's "and" because when sz > capacity(), the first size() elements use Cpp17MoveInsertable and the rest Cpp17DefaultInsertable.

But, in other words, when sz < capacity(), the invocation of resize() indeed does not requires the requirement Cpp17MoveInsertable for A, as shown in the example.

[xmh0511]

Moreover, consider this example

  std::vector<A> vec{};
  vec.reserve(2);
  std::cout<< vec.capacity()<<std::endl;  // #1
  vec.resize(10);  // #2

#1 prints 2 and #2 still be ok.

[xmh0511]

From the comment of the implementation of vector<T>::resize, it says it will default construct the element when sz > the first size(), see https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_vector.h#L1004

[JohelEGP]

When you do run out of capacity, you need the former set of requirements. Maybe what you want is to make the precondition of that set conditional. But I don't think that's editorial.

[xmh0511]

See my last comment above. I'm not sure whether the implementation didn't obey the requirement, or whether there are some inconsistencies in the standard. At least, according to your opinion, the requirement Cpp17MoveInsertable for void resize(size_type sz); should be conditional.

[frederick-vs-ja]

From the comment of the implementation of vector<T>::resize, it says it will default construct the element when sz > the first size(), see https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_vector.h#L1004

The comment doesn't follow the standard terminology, but IIUC the actual implementation is right here. In that case, the libstdc++ implementation is actually default-inserting new elements (with __uninitialized_default_n_a) and moving or copying old ones (with __uninitialized_move_if_noexcept_a).

We can't simply make Cpp17MoveInsertable or Cpp17DefaultInsertable conditional, because "Mandates" is missing here, and the well-formedness requirements, in my opinion, inappropriately appear in "Preconditions".

I think there are several possible defects.

• [vector.capacity]/16 suggests that old elements are copy-inserted under some conditions, but Cpp17CopyInsertable (which has semantic requirements) is not mentioned in Preconditions.
• Many named requirements in [container.alloc.reqmts]/2 (e.g. Cpp17DefaultInsertable) are merely requirements for well-formedness, and it's suspicious for them to appear in Preconditions instead of Mandates.
  • Cpp17MoveInsertable and Cpp17CopyInsertable have additional semantic requirements, should they be split?
• There is implementation divergence on resize: libstdc++ and msvc stl accept the non-move-insertable A, while libc++ rejects it. Currently all of them are conforming IIUC because Cpp17MoveInsertable only appears in Preconditions. If diagnosable parts of Preconditions are moved to Mandates, then the implementation divergence matters. It's not clear to me whether such divergence is intentionally allowed.

Anyway, I don't think this is editorial either. LWG issues seem needed.

[jwakely]

But, in other words, when sz < capacity(), the invocation of resize() indeed does not requires the requirement Cpp17MoveInsertable for A, as shown in the example.

Yes, but simply changing the preconditions from "and" to "or" would not help that problem and would be totally wrong. That would imply that resizing when capacity is exceeded has to work for an object that can only be default constructed, but not copied or moved. That's nonsense.

When shrinking the vector, neither Cpp17MoveInsertable nor Cpp17DefaultInsertable is required. When growing within the current capacity, only Cpp17DefaultInsertable is required. When exceeding the capacity, both are required. So the current wording is correct. In general, for an arbitrary call to resize, both are required.

So there is no editorial issue here, and any change to those requirements would be very non-editorial.

[jwakely]

• Cpp17MoveInsertable and Cpp17CopyInsertable have additional semantic requirements, should they be split?

At the time, there was a deliberate decision to not alter those requirements in Mandating the Standard Library:
Clause 21 - Containers library. That could be revisited now, but I don't know how much support there would be for doing that. It seems out of scope for an LWG issue, a paper would be needed.

[xmh0511]

So the current wording is correct.

The wording "and" requires both conditions are true, I think. However, the condition Cpp17MoveInsertable for A is false. This is the issue here.

[JohelEGP]

That just means it's UB.

(3.3)
Preconditions: the conditions that the function assumes to hold whenever it is called; violation of any preconditions results in undefined behavior.

[frederick-vs-ja]

However, the condition Cpp17MoveInsertable for A is false. This is the issue here.

This is not an issue of standard wording or implementations (at this moment). Using such non-Cpp17MoveInsertable A with resize results in UB, and thus implementations may support it as a conforming extension, or reject it.

[jwakely]

i.e. the wording is correct. There is no editorial issue here.

[xmh0511]

i.e. the wording is correct. There is no editorial issue here.

My original option is

I'm not sure whether the implementation didn't obey the requirement, or whether there are some inconsistencies in the standard.

AFAIK, the implementations of GCC and MSVC regarding resize all support the case when T is not Cpp17MoveInsertable, not sure whether Clang supports this behavior or not since I didn't dig further in Clang's standard library source code, Clang may be similar to GCC here. According to the wording, the behavior would be UB if T is not Cpp17MoveInsertable, however, all major implementations have consistent behavior. Agree that this issue touches the domain that is non-editorial

[frederick-vs-ja]

I'm not sure whether the implementation didn't obey the requirement, or whether there are some inconsistencies in the standard.

Implementations are conforming here IIUC, as currently they are not required to reject non-Cpp17MoveInsertable types.

The standard wording seemly has defects - copy insertion is suggested by the standard and conditionally used by all mainstream implementations (when the move construction is potentially throwing and copy construction is available), but the "Preconditions:" is only mentioning Cpp17MoveInsertable.

This is not limited to vector's resize. Perhaps almost all element-relocating operations of vector and deque are affected. I've tried to submit an LWG issue for this.

Clang may be similar to GCC here

Yes. But libc++ rejects non-(formally-)Cpp17MoveInsertable types when conditional move-or-copy-insertion is used. (Note that Clang can be used together with libc++, libstdc++, and MSVC STL.)