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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
