This topic comes up frequently during header review before each release. See https://codereview.qt-project.org/c/qt/qtbase/+/743937/5/src/gui/kernel/qwindow.h#203 as a current example.
Adding an overload to a member function (that existed in previous releases) breaks code that has been taking the address of that member function without explicitly specifying the overload. I.e. in the case above, code that does &QWindow::setFramePosition breaks, while QOverload<int, int>::of(&QWindow::setFramePosition) works (also before 6.12). It is perhaps reasonable to assume that nobody uses QOverload<>::of unless required. Not being able to add overloads to a member function is a significant constraint to API design. And it’s perhaps mostly meaningless; if the class author designed the API to be used as a slot, then it would/should be declared as a slot (even though unnecessary with pointer-to-member-function connect syntax; but QML will need the meta object entry). And that’s of course something we might need to fix in certain cases: member functions frequently used as slots in spite of not being declared as such can be moved into the slots-section. And while taking the address of an arbitrary member function is possible, it seems niche enough to not justify us constraining our API design. QUIP-6 [1] classifies this kind of addition as a Category A source-incompatibility, so acceptable, as user code can add the QOverload<>::of without version checks. Nevertheless, if we agree to categorically allow the addition of overloads to non-slot/signal functions, then we have more clarity, and save ourselves energy during header review. So, proposal to create a bit more clarity: - categorically allow the addition of overloads to regular member functions - Commits adding such overloads should come with a [ChangeLog][QtModule][Potentially Source-Incompatible Changes] footer. Perhaps tooling (AI or not) can help reviewers to watch out for this. - functions marked as slots (or signals) must not be overloaded 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”. [1] https://contribute.qt-project.org/quips/6 Cheers, Volker -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
