On Fri, 28 Feb 2020 at 22:35, Lars Knoll <lars.kn...@qt.io> wrote: > >> You'd see instead: > >> this->emptied().emit(...); > >> connect(foo, foo->emptied(), ...); > > I like this, then we could finally (and without hacks) have protected and > > private signals like in Qt 4. > > Would also solve the need for qOverload ? > This is all nice and fun to bike shed about, but I don’t think those proposed > solutions match the scope of the original problem (which was relatively > small). I don’t think a massive source compatibility breakage is what we > want, just because there is one std header using emit as a method name. > > And most of Qt’s signals are named in a way that makes it rather obvious it’s > a signal we’re looking at (e.g. fooChanged() or clicked()), so there’s no > need for an ‘emit’ in front to be clear. Some names are less obvious and the > ‘emit’ does help readability of our source code. > > So to shortcut this discussion a bit: I am completely opposed to a massive > SIC changes/efforts for our signals (like giving them ugly names like > emitClicked(), or signal objects).
Just turning signals into objects seems SC to me. But nothing will be SC if it has the whole-token "emit" in it. So if we want to introduce some sort of a more-structured C++ approach, we need to pick a different name for it to coexist with emit. > If people feel strongly, I am open to trying to find a way to keep some sort > of ‘emit’ prefix (whether that’s Q_EMIT or a [[qt::emit]] attribute), but I > do agree with Marc that we should in the long term try to get away from > having emit/signals/slots defined as macros (at least by default). Agreed. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
