[Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
Volker Hilsheimer
volker.hilsheimer at qt.io
Tue Sep 19 15:09:53 CEST 2023
> On 18 Sep 2023, at 14:46, Marc Mutz via Development <development at qt-project.org> wrote:
>
> TL;DR: "a" must not be a name of an existing function in Qt.
>
> On 18.09.23 10:15, Ivan Solovev via Development wrote:
>> Hi,
>>
>>> 1. an ADL-able calling convention: `using std::swap; swap(lhs, rhs);`
>>> 2. an implementation for built-in types: `std::swap`
>>> 3. an implementation for user-defined types: ADL `swap`
>>> 4. (optionally) a convenience wrapper: `std::ranges::swap()`, `qSwap`
>>
>> One more question here - do we want our users to be able to do (1), or
>> is it enough to expose only (4) to them?
>> The reason for my question is (again) naming, see below.
[…]
>> Anyway, it would be great to come to some kind of consensus about the
>> naming of the APIs, and move on to the actual implementation.
>
> +1
My take from this is that it’s next to impossible to reconcile the technical arguments for an unused (even if ugly) function name with having a good public API for our types. Not adding named public functions that are equivalent to C++20’s spaceship operator makes the problem less complex, but also reduces the value of doing the work to the point where it’s not worth it until we require C++20.
What Thiago wrote makes sense to me:
> On 31 Jul 2023, at 17:23, Thiago Macieira <thiago.macieira at intel.com> wrote:
> I'm not saying we have to. I'm saying that we should provide as API for our
> comparable types:
> * compare()
> * equals()
> * operators
>
> Whether the implementation of the latter uses the former two directly is to be
> seen.
Separating the implementation from the public API seems to me the only way to end up with a clean public API, while at the same time have a macro-friendly convention. The implementation can live in a private function with a name not suitable for a public API, e.g. “qt_equals/qt_compare”; those can be used by the macro declaring the operators.
Types for which we then want public APIs as well (and I agree that it’s strongly preferable to have this for all relevant types in the long run) can declare public equals()/compare() functions that ideally use the private functions.
I do not see the need for adding more qOperator type global functions.
Volker
More information about the Development
mailing list