[Development] Proposal: adding overloads to pre-existing member functions is ok as long as not a slot

[Marc Mutz]

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

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).

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.

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

Confidential
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260727/0ccda080/attachment.htm>