On Fri, 21 Feb 2020 at 22:11, André Pönitz <apoen...@t-online.de> wrote: > > On Fri, Feb 21, 2020 at 04:02:04PM +0200, Ville Voutilainen wrote: > > > 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. > > Christian is right and your conclusion is wrong.
My conclusion is fine. Your unsubstantiated claims don't make it wrong. > See the already mentioned example of debugging in code that follows > the convention of using signals only for inside-out communication: Buy a debugger that can skip code that you didn't write. > Emitting the signal may cause all kind of activity on the outside, > but in first approximation one can assume it doesn't change state in > the current object. So when drilling down in this situation > "ignoring" emit is indeed natural. Seems quite unnatural to me, considering that signal emissions reasonably often tend to result in further calls being made to the object. > > Thanks, Christian - that's the first ever plausible explanation for > > marking a signal emission. > This sounds a bit like the committee shot down the proposal to > not use 'emit' without even bothering to think about reasons why > there are users of this "nonsense", let alone tried to ask them. The committee shot down the proposal because 1) there are work-arounds to the problem, and we already use those work-arounds for similar issues with boost::signal 2) trying to avoid clashes with lowercase non-function-like macros is rather difficult 3) the scope of the problem is narrow 4) no existing code is broken _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
