> On 27 Jul 2026, at 12:20, Marc Mutz via Development > <[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 ;) If we agree that we can stop taking this into consideration for non-signals/slots, then let’s do that. > On 24.07.26 17:25, Volker Hilsheimer via Development wrote: > We might - perhaps independent of this proposal - want to add documentation > with good practices that help users write code that maximises source > compatibility. Such as “Don’t take the address of member functions that are > not marked as signals or slots”. > > > The std already forbids taking the address of (any, not just member) > function, and the solution is to wrap the call in a lambda and pass that > instead (which may decay to a function pointer, if needed). Indeed, and std makes the exception for functions that are designated as "an addressable function" https://en.cppreference.com/cpp/language/extending_std > 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. > On 27 Jul 2026, at 12:20, Marc Mutz via Development > <[email protected]> wrote: > So, yes, we may want to tell users not to take addresses of > non-signal/non-slot Qt functions, member or not. > > Another thing is to discourage use of `{}` as function arguments, because > that also causes ambiguity on every newly-added overload, so someone might > claim any overload added is actually B.1. Following that line of reasoning is > too limiting for us. Agree. Volker > Thanks, > Marc > > -- > Marc Mutz <[email protected]> (he/his) > Principal Software Engineer > > The Qt Company > Erich-Thilo-Str. 10 12489 > Berlin, Germany > www.qt.io > > Geschäftsführer: Mika Pälsi, Juha Varelius, Juha Puputti > Sitz der Gesellschaft: Berlin, > Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B > > > Confidential > -- > Development mailing list > [email protected] > https://lists.qt-project.org/listinfo/development -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
