[Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

[Thiago Macieira]

On Thursday, 14 September 2023 03:47:05 PDT Marc Mutz via Development wrote:
> Whenever you want to add an operation to _all_ types in the C++,
> built-in, as well as user-defined one, you obviously cannot use
> something that only works in classes: member functions don't work and
> neither do class-static functions. Simply because you can add neither to
> the type `int`, or the type `int[10]`.

Right, but the number of primitive types is limited, so we can exhaustively 
cover them with our implementation. That only leaves non-primitives, which can 
use member functions (whether static or not). But I have nothing against 
friend or hidden friend functions found by ADL.

> The gold standard, crystallized from 30 years of C++ experience _and_ 30
> years of Qt experience, requires four things:
> 
> 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`

That gold standard is horrible API. I'm not disputing it's the gold standard, 
I'm simply saying it's horrible API because people don't write "using 
std::swap; swap". That necessary trick is not discoverable until you've seen 
yourself, leads to pitfalls, and is must always be explained when taught, 
because it's not obvious why it's necessary. ADL is not the simplest portion 
of the language.

Therefore,

> In addition, experience tells us that we cannot afford to use the
> convenience wrapper outside generic code, because it's too slow to
> compile (cf. https://codereview.qt-project.org/q/topic:qSwap).

teachability, readability, and discoverability trump compilation speed. 
Compilation speed is important, but it's not more important than designing a 
good API. If it takes CPU time to compile good code, then so be it.

Exhibit A: ranges.

Ivan wrote:
> 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.

We can go with (4) only for now, to have good API. If we need to because it's 
unacceptably slow, we can then make (1) public, though we'd have to have 
chosen an acceptable API for it or we'd have to go and change it so it could 
be made public.


There's no conclusion in what direction to take in your email. I don't see 
anything that would refute my conclusions.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230920/8eda474d/attachment.bin>