[Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

Ville Voutilainen ville.voutilainen at gmail.com
Sat Feb 29 19:20:09 CET 2020


On Fri, 28 Feb 2020 at 22:35, Lars Knoll <lars.knoll at 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.


More information about the Development mailing list