[libcxx-commits] [PATCH] D96523: [libc++] Rewrite the tuple constructors to be strictly Standards conforming

Wed Nov 10 13:08:27 PST 2021

ychen added inline comments.

================
Comment at: libcxx/test/std/utilities/tuple/tuple.tuple/tuple.cnstr/PR31384.pass.cpp:52
+    std::tuple<Explicit> bar(std::move(d)); ((void)bar);
+#if TEST_STD_VER < 17
+    assert(count == 1);
----------------
Quuxplusone wrote:
> ychen wrote:
> > EricWF wrote:
> > > What's going on here? Why are there different answers depending on the dialect?
> > Yeah, I'm curious too. GCC/libstdc++ seems to have the same behavior. 
> https://godbolt.org/z/vGPYqEnfo
> C++14 sets `bar` to `tuple<Explicit>{ Explicit(42) }` by converting `d`'s `int(42)` using `Explicit(int)` and then building a tuple out of that.
> C++17 sets `bar` to `tuple<Explicit>{}` by invoking `d.operator tuple<Explicit>()`.
> Really, this test should be verifying `std::get<0>(bar) == [42 or 0]` as well as `count == [1 or 2]`.
> 
> I don't know exactly why C++14 hadn't been considering the conversion operator, or why C++17 started considering it, but I would assume that the reason is buried somewhere in the changes due to LWG2312, LWG2419, LWG2549. (Actually I'm very puzzled as to why the conversion operator wouldn't have been the obviously best match in C++14. Did C++17 change something in the core language about //conversion operators//, completely independent of tuple?)
> 
> Note that in October 2021, tuple's constructor constraints changed again due to LWG3121, LWG3155. I assume libc++ has not yet implemented those changes; I don't know if they'll affect this test case again at all.
After some digging, this seems from rG67ef14fe486e169f937737672d68. But still no idea what is changed in the standard text.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96523