On Thu, Nov 10, 2022 at 03:55:39PM +0000, Marc Mutz via Development wrote: > 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.
In the context of Qt, a library, that is used by code in unrelated projects, which may or may not use QueuedConnection on each signal, in fact for each individual connect, I cannot even remotely think of a non-owning interface unless this is somehow "owning in disguise", i.e. offer spans as parameters but effectively stashs away a deep copy in a safe place. Could you give a hint on what these several options for work-arounds may be? Andre' _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
