Staying in this thread for this particular point: > On 28 Jul 2026, at 11:52, Marc Mutz via Development > <[email protected]> wrote: > >> On 28.07.26 10:01, Volker Hilsheimer wrote: >>> 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 ;) > > > 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.
Hence this thread: If the maintainer of a class sees that we are missing overloads for a non-slot member, then they should be able to add what’s missing without worrying that we are breaking something that we promised somewhere not to break. If we make it explicit that one shouldn’t take the address of a non-slot member function, then we can focus the discussion on whether we have the right overloads for the code that we see people (or that we want people to) write. It should either way not be “willy-nilly”. But sometimes, adding overloads based on real-life experience of using an API is iterative, because we don’t get everything right. By freeing ourselves from the “is it a type A or type B SiC” discussion (by stating clearly that taking the address of a non-slot member is out of contract), we can work iteratively. Volker -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
