[Development] How qAsConst and qExchange lead to qNN

[Ivan Solovev]

> 1. It doesn't, obviously. If you emit signals, any signal argument must
>    be owning, or QueuedConnection cannot be used. Given that C++20
>    requires us to mark up views and non-owning ranges (enable_view,
>    enable_borrowed_range), I'm confident that we could detect attempts
>    to create such connections at compile- or, latest, at run-time, and
>    refuse them, or, since we need to serialize the arguments into a
>    QMetaCallEvent, anyway, also lifetime-pin, either by holding a weak
>    reference to the source object or by storing the data in the event in
>    an owning container.

I guess compile-time checks will be quite tricky, because we will need to check the threads
of both sender and receiver objects for the Qt::AutoConnection case.
Is it even possible at compile time?

As for the run-time check - I'm not a big fan of this approach either. It will be similar to the
metatype check that we have now (and which, I believe, is finally not needed with the latest
metatype changes). But I think that the code that compiles and runs, but then just refuses
to emit signals, is a potential source of errors and complaints.

> 3. Finally, the kinds of types I'm primarily thinking of in the context
>    of NOI are not Q_OBJECTS. It remains to be seen in which form or
>    shape co-routine-based reactive programming will complement or even
>    substitute signal/slots in the future.

But then we will still have all the Widgets/ItemModels/Netwroking and much more around.
And those will still use Qt containers.
So, I would personally agree with what Volker has proposed in his answer:

> We need to come up with a naming convention for getters that returns std::span so that we can add those APIs as alternatives.
> And perhaps we want symmetry between setters and getters working on spans, rather than making std::span setters overloads.

Best regards,
Ivan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20221110/f4e80d35/attachment.htm>