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