[PATCH] D151625: [clang] Add `clang::equality_operator_compares_members_lexicographically`

Nikolas Klauser via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue May 30 14:08:55 PDT 2023


philnik added a comment.

In D151625#4380735 <https://reviews.llvm.org/D151625#4380735>, @erichkeane wrote:

> I'm a little dense today perhaps, but I don't get the use case for this?  Can you ELI-EWG?  Is this an attribute we expect our users to use?  The name is horrifyingly long for users to use, but perhaps that is a good thing.

This is useful for libraries which have ADL requirements. Something like

  template <class T>
  struct Holder {
    T v;
  };
  
  struct Incomplete;
  
  template <class T>
  class TupleImpl {
    T v;
  
    bool operator==(const TupleImpl&) const = default;
  };
  
  template <class T>
  class Tuple : public TupleImpl<T> {
    bool operator==(const Tuple&) const = default; // ADL call here
  };
  
  void func() {
    Tuple<Holder<Incomplete>*> f; // Instantiation fails because Incomplete isn't defined
  }

has to work for `std::tuple` etc. to make them `__is_trivially_equality_comparable`, but the defaulted `operator==` will always try ADL (at least that's my understanding). To not make ADL calls, this attribute can be used instead, which basically say "trust me, my operator== does what the defaulted one would do".

Not sure what you mean by "Can you ELI-EWG?".
I agree that the name isn't great, but I couldn't come up with anything better that is still descriptive, and this attribute will probably only be used by very few libraries anyways (maybe just libc++, since this is pure QoI). As I said in the attribute description, the defaulted operator should be used if possible (which is probably the case in 99.9% of use cases).

(Note to self: maybe add the example as a test)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151625



More information about the cfe-commits mailing list