[PATCH] D41223: [libc++] Fix PR35491 - std::array of zero-size doesn't work with non-default constructible types.

Eric Fiselier via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sat Feb 3 16:59:07 PST 2018


EricWF added a comment.

In https://reviews.llvm.org/D41223#957308, @mclow.lists wrote:

> I'm wondering if it's not a better idea to have an explicit specialization for size == 0
>
>   template <class T>
>   class array<T, 0> {
>   // and so on.
>   };


I think that's probably more work than it's worth. I think we should change the primary template to support the bare minimum number of operations, and then let the rest of the operations blow up if users attempt to use them.

In https://reviews.llvm.org/D41223#957334, @lichray wrote:

> BTW, this is https://cplusplus.github.io/LWG/issue2157 , so please update `www` accordingly,


The `www` pages will get updated when the issue is actually accepted, which it currently isn't.
There is no place to put that information now.

> and also test `{{}}` cases.

I don't agree those cases are valid. That initialization syntax suggests there is something in the zero-sized array which is default constructible - or that users should be able to control construction of. I disagree with that.



================
Comment at: include/array:135
+  _LIBCPP_INLINE_VISIBILITY
+  static void __swap(_StorageT& __lhs, _StorageT& __rhs) {
+    std::swap_ranges(__lhs, __lhs + _Size, __rhs);
----------------
lichray wrote:
> Just asking: no compiler is dumb enough to not inline this entirely trivial wrapper so that it's okay to not to propagate `noexcept` here to avoid try...capture...terminate codegen in its caller side?
`_LIBCPP_INLINE_VISIBILITY` should force inlining. 


https://reviews.llvm.org/D41223





More information about the cfe-commits mailing list