[PATCH] D50106: [libc++] Fix tuple assignment from type derived from a tuple-like

Wed Feb 13 13:00:34 PST 2019

ldionne added a comment.
Herald added a subscriber: jdoerfert.

In D50106#1352469 <https://reviews.llvm.org/D50106#1352469>, @EricWF wrote:

> Our constructors still have the same bug,. Are you planning on fixing those as well? Doing so will require a metric butt-tonne of overloads.
>  If you're not planning on fixing the constructors, then can you explain why it's better that we're inconsistent?

We should fix the constructors too, but one thing at a time. We should have the 18 constructors that are mandated by the Standard, I think.

Yes, I hate that.

> Otherwises, this patch looks mostly OK. However, it makes a bunch of previously lazy SFINAE eager. Here are some tests:
>  https://gist.github.com/EricWF/88ceadf2bcdeef9f9d268b3a743dcd04

Good catch! Genuine question: In the Standard, we say in http://eel.is/c++draft/tuple.assign#10 (for `tuple<Types...>::operator=(tuple<UTypes...> const&)`):

> Remarks: This operator shall not participate in overload resolution unless `sizeof...(Types) == sizeof...(UTypes)` and `is_assignable_v<Ti&, Ui const&>` is `true` for all `i`.

This makes me wonder whether short-circuiting is mandated by the Standard. It certainly is a good QOI property to have it, but it's not clear to me this is required. WDYT?

> Is there a reason we can't use `__tuple_assignable` anymore?

We're not using `__tuple_types`, but there's no fundamental reason for that. I found it easier to have the logic inline. I do think we need to get back the short-circuiting behaviour that was there before (using your insanely clever SFINAE trick for left-to-right evaluation in a parameter pack expansion).

Repository:
  rCXX libc++

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D50106/new/

https://reviews.llvm.org/D50106