[Development] How qAsConst and qExchange lead to qNN

[Marc Mutz]

Hi Ivan,

On 10.11.22 11:03, Ivan Solovev via Development wrote:
> I wonder how your NOI-everywhere suggestion will work with the 
> signal/slot connections? Specially for the case when 
> Qt::QueuedConnection is used (explicitly or implicitly).

That's a very good question, thanks.

As a first reaction, three things come to mind:

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.

2. QML and QProperty do not appear to require passing the new value in a
    NOTIFY signals's parameter, so just not passing the argument is an
    option, too (but doesn't work with QueuedConnection, either).

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.

So, to summarize, I'd say that NOI works well with signal/slot, too, 
with the exception of QueuedConnection, where we have several options 
for work-arounds.

But this is definitely something we need to keep in mind, going forward, 
indeed.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at qt.io>
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B