On Friday, 28 February 2020 12:06:06 PST Matthew Woehlke wrote: > ...this might actually be better, since it would mean we still have MOC > generating the code for the signal. (I was trying to figure out how MOC > would generate the object initialization logic, and failing. I suspect > this would work better. I wonder if we could even introduce this new > style without breaking existing code source compatibility?) > > ...but I think connections would still look like either: > > connect(foo, &Foo::emptied, ...); > > ...or: > > connect(foo->emptied(), ...);
Yes, this can be added BC break for new signals and is also SC forwards- compatible ifor Qt 7: template <typename Signature> class QSignal { ... }; static QSignal<void(qint64 count)> bytesWritten() const; connect(foo, &Klass::bytesWritten, receiver, ...); Some magic in QObject::connect() can detect whether the return type is a QSignal and so match the QSignal's template parameter to the slot, instead of the PMF. It'll also call the static function to get the ID and this static function is generated by moc. We could also design QSignal so it's a C++20 structural type, so it could eventually be used as a non-type template parameter. But it can't be retrofitted without BC break to existing signals, since the function name is already used. The signal emission would be different: qEmit(&Klass::bytesWritten, count); or qEmit(q->bytesWritten(), count); -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development