[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