> -----Original Message----- > From: Lars Knoll <lars.kn...@qt.io> > Sent: Monday, 24 February 2020 1:40 PM > To: Mitch Curtis <mitch.cur...@qt.io> > Cc: Thiago Macieira <thiago.macie...@intel.com>; Qt development mailing > list <development@qt-project.org> > Subject: Re: [Development] A modest proposal: disable lower-case > keywords (emit, foreach, forever, signals, slots) by default > > On 24 Feb 2020, at 13:22, Mitch Curtis <mitch.cur...@qt.io > <mailto:mitch.cur...@qt.io> > wrote: > > > -----Original Message----- > From: Development <development-boun...@qt-project.org > <mailto:development-boun...@qt-project.org> > On Behalf Of > Lars Knoll > Sent: Monday, 24 February 2020 12:25 PM > To: Thiago Macieira <thiago.macie...@intel.com > <mailto:thiago.macie...@intel.com> > > Cc: Qt development mailing list <development@qt- > project.org <mailto:development@qt-project.org> > > Subject: Re: [Development] A modest proposal: disable > lower-case > keywords (emit, foreach, forever, signals, slots) by default > > > > On 21 Feb 2020, at 17:39, Thiago Macieira > <thiago.macie...@intel.com <mailto:thiago.macie...@intel.com> > > > > wrote: > > > > On Friday, 21 February 2020 04:59:02 PST Ville > Voutilainen wrote: > > > Having a keyword-extension to normal C++ is > ugly as sin, to some of > us. It causes fair amounts of "wtf is that?". > > > > That was my reaction when I first saw it, in 1999. > > Over 20 years later, I don't bat an eye. > > > > After 20 years, my eyes simply ignore any ‘emit’ in the source > code. > > In any case, I do understand why Qt added emit as a keyword > 25 years ago. > But today, we do have IDEs which should be able to figure > out on the fly > whether a function call is a signal emission (as they already do > for virtual vs > non virtual methods). So why don’t we move the over to be > a tooling > problem? Simply highlight signal emissions differently in the > IDE and you > don’t need a keyword for it anymore. > > > > That's one way of handling it, but I don't see the harm in keeping it > for those who want to use it. I don't think anyone has explained what that > harm is yet. > > > > It’s redundant. I would prefer to remove things that are redundant and > where the information could be provided by other means.
In that case, I share the same concerns as Andre in that it requires IDEs to have knowledge about Qt. I only use Creator, so it won't bother me, but it will affect others who are e.g. transitioning or are so used to another IDE that they'd never switch. Semi-related to this: Jira still doesn't know about QML as a highlighter syntax, 11 years later. :) > > > It’s also safer, as the keyword can be forgotten or applied to > the wrong places. > > > > I don't think I've ever seen this happen, and am curious as to why it's > dangerous. It might be misleading, but it couldn't cause harm, just a moment > of mild confusion. In terms of harm, I see it as on par with (or probably even > less dangerous than) an out-dated code comment. I think that marking signal > emissions aids the reader (and there is certainly *a lot* of Qt code that > could > e.g. use more code comments to aid people who have to maintain it). > > > > Of course it won’t change the logic. I could sprinkle my source code with tons > of “emit” all over the place and it wouldn’t change it’s meaning ;-) > > emit if emit (emit myVar == emit true) > mySignal() emit emit emit; > > But we could convey the information that this is a signal you’re calling > *reliably* through other means. This implies that the keyword is not > required. This sounds a lot like what Eike said, where the assumption is that because people can misuse it, they will. I don't know why anyone would use it in the wrong context except by accident. I agree that IDE highlighting is better because it's infallible, but like I said, I've never seen the keyword misused. > Cheers, > Lars > > > > Cheers, > Lars > > > _______________________________________________ > Development mailing list > Development@qt-project.org <mailto: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
