[Development] More Q_SLOTS! (was: Re: Proposal: adding overloads to pre-existing member functions is ok as long as not a slot)

[Marc Mutz]

On 28.07.26 10:01, Volker Hilsheimer wrote:

On 27 Jul 2026, at 12:20, Marc Mutz via Development <development at qt-project.org><mailto:development at qt-project.org> wrote:

This is the status quo: A.1 in QUIP-6 makes it crystal clear it's allowed. Why does it come up frequently?


Well, you asked on https://codereview.qt-project.org/c/qt/qtbase/+/743937/5/src/gui/kernel/qwindow.h#203 "whether it's pulling it's weight (it breaks taking the function's address, e.g.)."

So you tell me ;)

I wasn't questioning whether it's allowed. I was questioning whether the overload pulls it's own weight, considering that a) it's SiC (albeit Type A) and b) all the other setters in the class don't get the same treatment. So the SiC is one aspect, and just because we've allowed ourselves the leeway doesn't mean we should use it willy-nilly. We also added REMOVED_SINCE to avoid actual overloading when adding new arguments to an existing function, so while we can add overloads, we also clearly try to limit that.


On 28 Jul 2026, at 02:13, Thiago Macieira <thiago.macieira at intel.com><mailto:thiago.macieira at intel.com> 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.

Thanks,
Marc

--
Marc Mutz <marc.mutz at qt.io><mailto:marc.mutz at qt.io> (he/his)
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io<http://www.qt.io>

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

Public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260728/7e5976cd/attachment-0001.htm>