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

[Mitch Curtis]

> -----Original Message-----
> From: Development <development-bounces at qt-project.org> On Behalf Of
> Ville Voutilainen
> Sent: Friday, 21 February 2020 3:02 PM
> To: Christian Kandeler <Christian.Kandeler at qt.io>
> Cc: development at qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> 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.

Personally I find it a bit concerning that you don't consider readability or maintainability a plausible explanation for annotating code with emit. Though I can rest easy with the knowledge that you're not the sole authority for what constitutes a plausible explanation, despite how you worded it.

I can only assume that that same mindset must also encapsulate all of the developers who never wrote any comments for their code because... it made sense to them and that's all matters.

> 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.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development