On 19 Sep 2023, at 15:49, Marc Mutz via Development <development@qt-project.org> wrote: So I ask: Please let us roll out the framework with one of equal/eq/order/ordering/cmp (your choice, but quickly!), to set a status quo against which to benchmark any potentially-superior solutions, and then the ML can finish bikesheddding and if the discussion yields something better, I think I speak for Ivan, too, when I say that we're committed to porting to that.
Thanks, Marc Given the state of https://codereview.qt-project.org/c/qt/qtbase/+/481410/3 right now (needs rebase, doesn’t build with either C++17 or C++20 for me on macOS with apple’s clang), my suggestion would be to go “very explicit" with the names for O and E, at least for the time being. O = compareThreeWay, following std::compare_three_way (https://en.cppreference.com/w/cpp/utility/compare/compare_three_way) E = comparesEqual The vast majority of code will use operators to compare two objects. Code that somehow needs the concept spelled out can type it out as well. In contrast to `swap` we don’t need to be short here, given that the operator-shorthand exists. Once the chain of commits is up-to-date it will be easier to play around with alternatives, to see if we can come up with a technical solution that allows us to use `equals` and `compare` as names for E and O, as those are established APIs in Qt. You lost me here, but I assume that you're talking about what I call (4). There must be _one_ global template. It calls (2) or (3) via (1). Everything else is a novel idea that must argue against 30 years of C++ and 30 years of Qt experience. qFoo would be that (4). A class-static cannot be that (4). Yes, I’m not questioning that we need Qt::equals. But do we need (4)? you marked it as optional yourself. If we can have (1), i.e. using Qt::equals; equals(a, b); why do we need qEquals?
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
