erichkeane added a comment. In D151625#4382227 <https://reviews.llvm.org/D151625#4382227>, @philnik wrote:
> 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) ELI-EWG: "Explain-like-I'm Evolution Working Group" :) Its a touch of a joke, there is a common reddit 'ELI5' (Explain like I'm 5), so I'm equating the C++ EWG to needing 5-year-old-esque explanations. I can see the value to that I guess? I don't have a good idea on the name, but perhaps folks from @clang-language-wg might have an idea? Either way, I want to give it a little time for folks to comment. That said, it DOES seem that the pre-commit-CI failures are related, so those need fixing as well. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D151625/new/ https://reviews.llvm.org/D151625 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
