On Fri, Feb 21, 2020 at 02:41:35PM +0200, Ville Voutilainen wrote: > On Fri, 21 Feb 2020 at 14:30, Mitch Curtis <mitch.cur...@qt.io> wrote: > > > > > without any annotation is not what we want. We'd miss vital > > > > information > > > and reduce readability. Can you please explain what that vital > > > information is? > > How can you tell if it's a signal being emitted or just a function > > call without the emit syntax? With the emit syntax before the signal > > emission, it's immediately obvious that it's a signal. Not all > > signals follow the *Changed() naming convention, nor should they, so > > it becomes even less obvious in those cases. > > Why do I need to know that it's a signal being emitted?
The question is not why you need to know that, but why apparently quite a few people feel that using an empty macro adds value. My best guess is that different people have different reasons here. I myself usually prefer shorter code to longer doing the same, so my natural reaction would be to drop 'emit'. However, I am actually ok with having it, and that's mainly because it signals the use of a convention in the code I usually operate on: Signals are use to communicate to an unknown outside, so one might spend a thought e.g. on how much work this might trigger, whether threads play a role etc. > How is that "vital information"? It's not *vital*, and it's irrelevant to the compiler. It's there for the human reader. int i = 2; is practically the same as int fjwqDwerewnrUHBLswd = 2 for an compiler, still some people might prefer one of them. Andre' _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
