> On 28 Jul 2026, at 11:52, Marc Mutz via Development > <[email protected]> wrote: >>> On 28 Jul 2026, at 02:13, Thiago Macieira <[email protected]> wrote: >>> >>> The connection mechanism is slightly more efficient when you pass a >>> function >>> pointer, member or not, because it can tell what arguments you meant to >>> receive. When you pass a functor/lambda, the receiver may itself have >>> overloads or may be a template, so we can't do that. That means we can't >>> look >>> at the receiver's arguments to do interesting things; instead, we must try >>> things and see if they compile. >> >> >> Also, to the compiler, a lambda is always a unique type (even if the >> operator() has the same prototype, the captures might be different etc), so >> using lambdas in connect statements requires the compiler to general several >> specialisations of QtPrivate::QSlotObject that cannot be reused. Making >> several connections to the same kind of function pointer (i.e. same >> prototype) on the other hand gives the compiler more options to reuse an >> existing QSlotObject specialisation. > > > I optimized QSlotObjectBase for a large number of instantiations, but > Thiago's comment shows its a concern above the code bloat aspect. > > I guess we should just start marking slots as Q_SLOTS again. I have observed > a marked decline in Q_SLOTS in API reviews. Stuff (like setters on QObject > subclasses) that would have been marked as Q_SLOTS in Qt 4 aren't, anymore, > because "you can connect to non-slots" these days. We were also thinking > about routing PMF-syntax calls addressing actual slots through qt_metacall() > again, to avoid them accessing partially-deleted objects. > > So IMHO, that's the discussion to be had: should we do more Q_SLOTS again? > > I'm biased, obviously, but, to me, the answer is clear.
Agree, a function that might be connected to a signal should be marked as a slot. That’s not just a question of technicality, but also of communicating intent. Volker -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
