> On 24. Feb 2020, at 13:48, Mitch Curtis <mitch.cur...@qt.io> wrote: > >> -----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.
I wasn’t thinking of malicious misuse. But an “emit” in front of something does not make it “obvious” that it _has_ side effects of a signal. Just that someone (maybe) commented that it has that (or maybe that emit is some leftover of some refactoring). It is just a comment in the code. It is not more than a regular code comment. I still don’t see why we need a fake keyword for it. finshed(); // emit has the same semantics, and actually makes it _clear_ to anyone that it is just a comment without meaning in C++. And should be as toolable as “emit finished();” Actually we have a suggestion for Qt Creator to automatically show an automatic comment/annotation “ } // namespace Foo” if the brace closes a namespace. Sounds similar. It might be more ugly than “emit finished();” (Purely subjective?) But “emit” doesn’t seem to be in our future anyhow. 1. qEmit(finished()); ? 2. [[qt::emit]] finished(); ? 3. Q_EMIT finished(); ? 4. finished(); // emit ? 5. signalFinished(); ? (has the advantage that you can code complete for signals even in an IDE that doesn’t have explicit support for connect(...) or any Qt. Maybe difficult to adapt in Qt.) 6. finished(); ? I don’t know, but since 3, 4, and 6 are already open to anyone now, I don’t think we need 1 or 2, or (n+1) > >> 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 -- Eike Ziller Principal Software Engineer The Qt Company GmbH Erich-Thilo-Straße 10 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
