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

Ville Voutilainen ville.voutilainen at gmail.com
Fri Feb 21 15:02:04 CET 2020


On Fri, 21 Feb 2020 at 15:44, Christian Kandeler
<Christian.Kandeler at qt.io> wrote:
>
> On Fri, 21 Feb 2020 15:00:53 +0200
> Ville Voutilainen <ville.voutilainen at gmail.com> wrote:
>
> > On Fri, 21 Feb 2020 at 14:58, Sérgio Martins <sergio.martins at kdab.com> wrote:
> > > > Why do I need to know that it's a signal being emitted? How is that
> > > > "vital information"? I could just as well
> > > > invoke any other callback, but I find myself not exactly yearning for
> > > > being able to write
> > > > callback somethingHappened();
> > >
> > >
> > > Signals have different semantics than regular functions.
> >
> > In what way?
>
> They typically call back into "upper layers", which is worth considering on the calling side, e.g. due to the danger of inconsistent state getting accessed if you don't emit the signal at the end of a function, to name just one tyical pitfall.
> I, for one, definitely want to see whether I am emitting a signal or not.

Right; the claims that you can ignore signal emits when looking at a
piece of code or expect that they
don't affect the current scope are exactly backwards.

A signal emitted yields to a coroutine scheduler that runs arbitrary
callbacks, which in case of direct connections absolutely can affect
the current scope.

Thanks, Christian - that's the first ever plausible explanation for
marking a signal emission.

Getting back to macro vs. function.. I think using a function wrapper
is fine, considering that signals can't
meaningfully return, so the prvalue/xvalue issue doesn't arise. We
could even have qEmit() return void,
to prevent a possible return value from being (ab)used.

Yeah, I'm sure we'll have no trouble finding people who think

qEmit(mah_bucket_callback());

is unacceptably ugly compared to

qEmit mah_bucket_callback();

The big advantage of that ugly version is that it's regular C++
without using macros.

At the risk of riffing on this a tad too far, we could alternatively
consider using an operator on a global dummy
qEmit object, but that runs a risk of getting into precedence games.


More information about the Development mailing list