On 28.07.26 10:01, Volker Hilsheimer wrote: On 27 Jul 2026, at 12:20, Marc Mutz via Development <[email protected]><mailto:[email protected]> 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 <[email protected]><mailto:[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. Thanks, Marc -- Marc Mutz <[email protected]><mailto:[email protected]> (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
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
