> -----Original Message----- > From: Development <development-boun...@qt-project.org> On Behalf Of > Ville Voutilainen > Sent: Friday, 21 February 2020 3:02 PM > To: Christian Kandeler <christian.kande...@qt.io> > Cc: development@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.kande...@qt.io> > wrote: > > > > On Fri, 21 Feb 2020 15:00:53 +0200 > > Ville Voutilainen <ville.voutilai...@gmail.com> wrote: > > > > > On Fri, 21 Feb 2020 at 14:58, Sérgio Martins <sergio.mart...@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@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
