[libcxx-commits] [PATCH] D108250: [libc++][spaceship] Implement std::tuple::operator<=>

Fri Sep 24 00:38:04 PDT 2021

mumbleskates added inline comments.

================
Comment at: libcxx/test/std/library/description/conventions/expos.only.func/synth_three_way.pass.cpp:1
+//===----------------------------------------------------------------------===//
+//
----------------
Well, this file reproducibly causes g++-11 to segfault at compile time. fantastic

================
Comment at: libcxx/test/std/utilities/tuple/tuple.tuple/tuple.rel/three_way.pass.cpp:172-173
+    typedef std::tuple<int, unsigned long, SpaceshipNoEquals> T2;
+    // Spaceship operator with no == operator falls back on the < operator and weak ordering.
+    ASSERT_SAME_TYPE(decltype(T1() <=> T2()), std::weak_ordering);
+  }
----------------
mumbleskates wrote:
> Quuxplusone wrote:
> > This is somewhat counterintuitive, right? What is the behavior of `T1() == T2()` in this case — does it call tuple's `operator==`, or does it not exist? Should we test that?
> `operator==` does not fallback to be rewritten in terms of `operator<=>`, so yeah tuple's `operator==` is expectedly undefined in this case.
> 
> It doesn't really hurt to test it, but I think this would belong in the `eq.pass` test instead.
I just spent like 45 minutes trying to make this test work. it can be impossible to use `==` without error, as expected, but when a no-`==` type is part of a tuple i cannot get that to be detectable with sfinae or even with concepts and it's unclear to me why that is.

the operator is implemented as a call to a cascade of template functions in template classes, but the end result is still ill formed and (i would think) should be eliminated, and it's beyond my current ability to see why.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108250