P3737 `std::array` is a wrapper for an array! needs feedback from MSVC maintainers

[frederick-vs-ja]

It seems that new specification for [array.zero] (as of 0439353) will break ABI for MSVC STL. The new specification requires triviality but MSVC STL's implementation strategy sometime fails to provide, despite that triviality was discussed before. Perhaps we should only require that for each desired property which array<T, 1> doesn't have, it is unspecified (or implementation-defined?) whether array<T, 0> has.

Also, MSVC STL tends to avoid terminate wherever possible, see also microsoft/STL#5560. Would it be better to say "implementation-defined terminating function" instead of std::terminate?

[eisenwave]

On the second point, maybe we can keep it more vague as to how termination happens.

The first point doesn't matter because MSVC's implementation is non-compliant anyway. It's only non-trivial because their array<T,0> behaves exactly like array<T,1> and calls constructors and destructors of an element that isn't meant to exist.

So who cares, they are non-compliant and will stay non-compliant no matter what changes we make to std::array.

[frederick-vs-ja]

Hmm, it's unclear to me whether the current specification requires that "default-constructing an array<T, 0> doesn't (default-)construct a T object", although such behavior is desired. But it's clear that the newly proposed one does.

[eisenwave]

Hmm, it's unclear to me whether the current specification requires that "default-constructing an array<T, 0> doesn't (default-)construct a T object", although such behavior is desired. But it's clear that the newly proposed one does.

https://eel.is/c++draft/array.overview#1 states that an array<T, 0> stores 0 elements of type T, so it's pretty obvious that it's not meant to be some arbitrary amount of elements different from that.

If it's okay to store one element in a zero-length array, then it's also okay for an empty std::vector to store one billion elements because who cares, words in the standard clearly don't matter.

[frederick-vs-ja]

Hmm, it's unclear to me whether the current specification requires that "default-constructing an array<T, 0> doesn't (default-)construct a T object", although such behavior is desired. But it's clear that the newly proposed one does.

https://eel.is/c++draft/array.overview#1 states that an array<T, 0> stores 0 elements of type T, so it's pretty obvious that it's not meant to be some arbitrary amount of elements different from that.

If it's okay to store one element in a zero-length array, then it's also okay for an empty std::vector to store one billion elements because who cares, words in the standard clearly don't matter.

It's arguable to say such a T object is not an element because it's not in the (empty) range [begin(), end()).

Such difference is critical for basic_string. A basic_string needs to store size() + 1 value_type objects, and the last one (the null terminator) is not considered as an element.

[eisenwave]

It's arguable to say such a T object is not an element because it's not in the (empty) range [begin(), end()).

Then it's arguable that an empty std::vector can store one billion objects and say that none of them are elements. By that logic, any standard library function that doesn't explicitly say it doesn't, can allocate memory, call constructors for no reason, terminate execution, and do all sorts of things that you didn't ask for by omission, rendering the standard meaningless.

In any case, that's obviously not the intent of the wording. std::string small object optimizations are a bit underspecified, but the construction of char isn't observable anyway, so it doesn't meed that much attention. The construction of some arbitrary T in a std::array<T> very much deserves attention.

[frederick-vs-ja]

Then it's arguable that an empty std::vector can store one billion objects and say that none of them are elements.

This is not quite different from MSVC STL's another unfortunate choice for which fixing needs to break ABI. Currently MSVC STL makes a default-construct (and moved-from) empty allocator-aware container hold dynamically allocated "contain proxy" object (used for debug info) in debug mode. Also, libstdc++'s deque is similarly poorly designed - such an empty (and moved-from) deque holds some dynamically allocated buffer.

Given that allocator and deallocation can also perform user-provided operations, such an undesired allocation is as observable as an undesired object. And the standard requirements on noexcept (introduced in N4258) compromised for these poor choices.

[eisenwave]

microsoft/STL#5583

[YexuanXiao]

Should array<T, 0> have the same trivially constructible and trivially destructible properties as T?
I don't see any requirements about this in P3737R0. The MSVC STL currently value-initializes _Elems, which is reject static_assert(std::is_trivially_constructible_v<std::array<int, 0>>); but accepted static_assert(std::is_trivially_constructible_v<std::array<int, 1>>);.

[eisenwave]

Should array<T, 0> have the same trivially constructible and trivially destructible properties as T?

It should at least not be non-trivially-default-constructible when T is, i.e. not "make things worse". I think it's worth including that in the proposal.

GCC and Clang don't have the problem because they contain an empty class object or an array of empty class objects respectively, so they don't risk creating erroneous values within std::array<T,0>, but the MSVC implementation does have that risk. I suspect that's why MSVC value-initializes it.