[PATCH] D27606: [libcxx] Fix tuple construction/assignment from types derived from tuple/pair/array.

[Eric Fiselier via Phabricator via cfe-commits]

EricWF accepted this revision.
EricWF added a reviewer: EricWF.
EricWF added a comment.

Accepting revision. @mpark mentioned that this was good to go offline.  Ignore the inline comment about `base.operator=`, phab won't let me delete it.



================
Comment at: include/tuple:884
         tuple(allocator_arg_t, const _Alloc& __a, _Tuple&& __t)
             : base_(allocator_arg_t(), __a, _VSTD::forward<_Tuple>(__t)) {}
 
----------------
This should be fixed


================
Comment at: include/tuple:915
         tuple&
-        operator=(_Tuple&& __t) _NOEXCEPT_((is_nothrow_assignable<base&, _Tuple>::value))
+        operator=(_Tuple&& __t) _NOEXCEPT_((is_nothrow_assignable<base&, _QualTupleBase>::value))
         {
----------------
mpark wrote:
> A general comment about using the `base` in noexcept condition. I remember for `variant` we wanted to express it directly rather than delegating it to the "base". Does that also apply here?
Yes. probably. but this is existing code. I'll fix that in another patch. Plus it's really hard to state this noexcept directly since you need to expand the input argument into its tuple-types.


================
Comment at: include/tuple:917
         {
-            base_.operator=(_VSTD::forward<_Tuple>(__t));
+            base_.operator=(_VSTD::forward<_QualTupleBase>(__t));
             return *this;
----------------
mpark wrote:
> Here and elsewhere, why do we bother with `base_.operator=(...);` as opposed to just `base_ = ...;`?
I think the reason for not using `base_ = ...` is because that can select different conversion sequences IIRC.


https://reviews.llvm.org/D27606