> 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
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
