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. 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
