Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Tuesday, 14 April 2020 20:54:57 -03 Nathan Myers wrote: > I see that you are confused about the origins of Posix > and Unix networking practices, as well as WG21's. ISO > WG21 was convened in 1990. The ntohs etc. macros precede > 1990. Qt does not. Yes, it does. The first release was in 1994, but the first papers that talked about signals, slots, emission and QObject are from 1989. The PhD thesis by one of Trolltech's founders (before founding Trolltech) was still surprisingly compileable with Qt 3; for Qt 4 and 5 there was mostly a change about how the main window is defined. > Among thousands, maybe millions of libraries, Qt, all alone > among them, claims authority on its own say-so to impose new > keywords on the core language it depends upon. OpenMP comes to mind too. Another one was the language on top of C to access databases, by Oracle (can't recall the name). And besides, those are empty macros to help a code generator find instructions. Hardly new in 1990 and not unique in 2020 either. > Numerous other libraries could have got clever with macros. > But they didn't. That was not because they couldn't think of > it. They are, instead, aware of their place in the ecosystem. min and max don't come to your mind? See windows.h. How about major and minor? See sys/sysmacros.h. > Qt's failing was criticized immediately upon release. Can you point to the criticism emails or USENET posts? The one comment I really know about the release was Matthias Ettrich's post on USENET about it being really easy to use and calling to action to create a desktop for Unix. Then Miguel de Icasa got involved and criticised Qt, but not on the language or ease of use, but the licence. I know a lot of people who criticise moc, even today. But I don't consider it any worse than yacc or gperf or any other code generator. If and when the standard provides reflection, it may go away. In any case, those complaints about moc don't apply: it would still exist, even if the markers it scanned for were not macros. > Each day since, it has again not been fixed: day after day, > year upon year, failure piling on failure, thousands deep. > All fixable with one simple patch. You do realise you cannot patch the thousands of different Qt-based applications with a single patch, right? Each and every one of them requires a patch. Even a simple search-and-replace can break code if not done properly. Ironically, the code most vulnerable is that which already uses QT_NO_KEYWORDS and uses a library that uses "signals" as an identifier. Anyway, the decision is made: we will deprecate the lowercase keyword-like macros. But since we don't like to break users' code bases any more than the standard does, it needs to be a process over a couple of releases. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 4/14/20 5:28 AM, Lars Knoll wrote: On 14 Apr 2020, at 10:17, Nathan Myers mailto:n...@cantrip.org>> wrote: On 4/13/20 3:41 PM, Ville Voutilainen wrote: It also doesn't require smoking crack to suggest that WG21 considers code breakage due to new identifiers clashing with existing macros; they've done so before, when the Networking TS and its functions with names like ntohs and htons clashed with macros. Ville is certainly aware that the instance he cites involved macros that (a) commonly appear in vendor System C Library headers, from numerous sources, and (b) *long* precede the existence of ISO WG21. Neither of the above applies to Qt header abuses, which (as Marc has noted) are trivially remedied by fixing a single header file in a single library distribution, and could have been as easily fixed on any day of the past 20+ years. What kind of argument is that? htons as a macro was worth considering, but the ones in Qt are not? Exactly. The argument distinguishes components of official ISO Standard 9945, already implemented and shipping from (as noted) numerous organizations at the time that ISO WG21 was convened. Such organizations each ship an independently implemented C library, and have no obligation or, often, inclination to pay the slightest attention to the needs of a C++ Standard. I.e., WG21 would have been shipping its Standard Library Networking TS into a surrounding environment where it would not work. Qt, on the other hand, is fundamentally dependent on the environment provided by ISO Standard 14882, and stands to benefit from interoperating cleanly with other users of 14882. Its users also benefit where Qt interoperates cleanly with other libraries, not excluding the Standard Library. Fixing the htons macro also "only requires changing one place" in the System C library. You are forgetting, that both changes break a huge amount of user code out there. And Qt’s macros have been around for about just as long (25 years), so they also *long* precede the existence of ISO WG21. I see that you are confused about the origins of Posix and Unix networking practices, as well as WG21's. ISO WG21 was convened in 1990. The ntohs etc. macros precede 1990. Qt does not. Yes, there is a difference because Qt is not a system library, but it is nevertheless very widely used, so bringing the compatibility problem up as something to consider for the WG was certainly the right thing to do. Many, many libraries are widely used. Many of those are *much* more widely used than Qt. Yet, their maintainers know better than to try to claim new core language keywords. This point is worth dwelling on. Among thousands, maybe millions of libraries, Qt, all alone among them, claims authority on its own say-so to impose new keywords on the core language it depends upon. Asking the ISO WG21 C++ Standard committee to compensate for one library's extended process failure is, at best, rude and foolish. I do agree that we should change this and get rid of the lower case macros. But blaming Qt here for keeping compatibility for our users while saying this is ok for system C libraries is just as rude. I am not personally responsible for the ISO WG21 Library Evolution Working Group's so *resoundingly* rejecting Marc's proposal. I simply interpret the fact, for your benefit. You are of course free to impute to the committee any rudeness you like, or folly. Many people talk about WG21's folly, but it is only our own folly that is under our control. It would not be at all surprising if uses of all the other abused names--signals, slots, etc--show up in key components of C++23. Asking the committee to change them could not reasonably be expected to produce a peaceful outcome. The outcome of this last asking was plenty peaceful It is generally a mistake to confuse a polite but firm rejection with an invitation to dance. Marc's proposal is far too modest. Just change the default, in a single step: eliminate the abusive macros, as any responsible organization would have done *decades* ago. (An accompanying apology for past abuse would not be out of place.) Anybody who wants to keep using the abusive macros already knows how. They will also know that they are deliberately choosing to do The Wrong Thing. Why? The users of emit don't care it's a macro, and if they never use osyncstream, they don't run into this problem. Forcibly breaking their code without any sort of soft migration path doesn't seem like a user-friendly way to approach it. Ville is certainly aware of why common lower-case words as macros are ill-advised in public library headers. He is also aware that the ISO Standard C++ Library is not the only place where lower-case words are commonly used as properly-scoped identifiers. The world offers thousands of useful libraries, each equally or more subject to disruption by a single needlessly ill-disciplined library header. It is never the wrong time to step up and do the
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
14.04.2020, 22:18, "Ville Voutilainen" : > On Tue, 14 Apr 2020 at 12:31, Lars Knoll wrote: >> What kind of argument is that? htons as a macro was worth considering, but >> the ones in Qt are not? >> >> Fixing the htons macro also "only requires changing one place" in the >> System C library. You are forgetting, that both changes break a huge amount >> of user code out there. And Qt’s macros have been around for about just as >> long (25 years), so they also *long* precede the existence of ISO WG21. > > Well, there are multiple C libraries. So it was never just one place > for that particular problem. I think there are other issues with htons and similar functions: 1) on Unix-like systems C library is integral component of OS which cannot be easily updated to newer version, and while it may be possible to use different libc to build user application it means that those application will not be able to use any libraries shipped with OS without risk of conflict; 2) there is no standard way to have inline functions in C without requiring C99, while inlining these particular functions may be crucial for performance of network-related applications. > > However, we should recognize that "could have been as easily fixed on any > day of the past 20+ years" applies 100% as well to those macros. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Tue, 14 Apr 2020 at 11:22, Nathan Myers wrote: > Neither does Ville have authority to speak on behalf of > the Library Evolution Working Group. The slight difference, of course, is that I enumerated bits of rationale that were actually uttered in that discussion, rather than colorful suggestions of how the majority of LEWG must think that widespread abuse of a variant of cocaine is the sole reason why such a proposal even came to their plate. > The WG was firm but polite, this once. Expect greater > firmness, and less politeness, next time. Take the hint. Now, that *is* an invitation to dance. :D I shall, however, mostly pass the opportunity. In case you wish to ask me what hints I will and will not consider when evaluating whether to propose some hypothetical thing to the committee, feel free to ask for elaboration privately. > Asking the ISO WG21 C++ Standard committee to compensate > for one library's extended process failure is, at best, > rude and foolish. There's nothing rude in providing information that the committee may not have been aware of about compatibility issues with new standards. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Tue, 14 Apr 2020 at 12:31, Lars Knoll wrote: > What kind of argument is that? htons as a macro was worth considering, but > the ones in Qt are not? > > Fixing the htons macro also "only requires changing one place" in the System > C library. You are forgetting, that both changes break a huge amount of user > code out there. And Qt’s macros have been around for about just as long (25 > years), so they also *long* precede the existence of ISO WG21. Well, there are multiple C libraries. So it was never just one place for that particular problem. However, we should recognize that "could have been as easily fixed on any day of the past 20+ years" applies 100% as well to those macros. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 14 Apr 2020, at 17:02, Matthew Woehlke
mailto:mwoehlke.fl...@gmail.com>> wrote:
On 14/04/2020 05.28, Lars Knoll wrote:
I believe there is mostly a consensus here to find a way to get rid
of those macros. But many of our users do seem to like the ‘emit’
keyword as an annotation to a signal emission, and it is being used
extensively in existing code bases.
You know what would solve this? The ability to define a *reflection* operator
(with proper name scoping) that could apply to statements and/or access
protection specifiers.
class MyObject
{
Qt::Q_OBJECT;
public Qt::slots:
...slots here...
};
MyObject::foo()
{
Qt::emit this->bar();
using namespace Qt;
emit this->bar();
none->emit(...); // *not* the Qt::emit operator
}
If we played this right, maybe we could even reimplement MOC using reflection?
(Stuff like Q_PROPERTY however might be hard, depending on if these operators
are allowed to take a *space* delimited list of arguments rather than comma
delimited.)
Maybe, but we can’t solve it with current C++ standards. I think we should
simply go and change the default for the QT_NO_KEYWORDS macro in Qt 6. Then,
it’s Q_SIGNALS, Q_SLOTS and Q_EMIT by default, and you’ll need to use a
#define to get them back: https://codereview.qt-project.org/c/qt/qtbase/+/297053
Cheers,
Lars
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 14/04/2020 05.28, Lars Knoll wrote:
I believe there is mostly a consensus here to find a way to get rid
of those macros. But many of our users do seem to like the ‘emit’
keyword as an annotation to a signal emission, and it is being used
extensively in existing code bases.
You know what would solve this? The ability to define a *reflection*
operator (with proper name scoping) that could apply to statements
and/or access protection specifiers.
class MyObject
{
Qt::Q_OBJECT;
public Qt::slots:
...slots here...
};
MyObject::foo()
{
Qt::emit this->bar();
using namespace Qt;
emit this->bar();
none->emit(...); // *not* the Qt::emit operator
}
If we played this right, maybe we could even reimplement MOC using
reflection? (Stuff like Q_PROPERTY however might be hard, depending on
if these operators are allowed to take a *space* delimited list of
arguments rather than comma delimited.)
--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 14 Apr 2020, at 10:17, Nathan Myers mailto:n...@cantrip.org>> wrote: On 4/13/20 3:41 PM, Ville Voutilainen wrote: On Mon, 13 Apr 2020 at 06:11, Nathan Myers mailto:n...@cantrip.org>> wrote: The prevailing feeling in the room, when the vote was taken, was that Qt people MUST BE SMOKING CRACK if they think the ISO 14882 C++ Standard should or would tiptoe around Qt's aggressive abuse of lower-case macro names. That Qt has abused them for a long time makes the abuse exactly that much *less* excusable. To wit: you cannot claim you didn't know better. While the argument was indeed made that the prolonged time we have had lower-case macros in our public API makes accommodating them less appealing for WG21, the 'prevailing feeling' is something where you speak on behalf of a working group without the authority to do so, and it's highly questionable whether that feeling was as prevailing as you suggest. Neither does Ville have authority to speak on behalf of the Library Evolution Working Group. But Ville, Marc, and I are all well-equipped to interpret the (unusually large) number of "Strongly Against" votes cast in this instance. Sugar-coating the outcome of that vote benefits no one. The WG was firm but polite, this once. Expect greater firmness, and less politeness, next time. Take the hint. It also doesn't require smoking crack to suggest that WG21 considers code breakage due to new identifiers clashing with existing macros; they've done so before, when the Networking TS and its functions with names like ntohs and htons clashed with macros. Ville is certainly aware that the instance he cites involved macros that (a) commonly appear in vendor System C Library headers, from numerous sources, and (b) *long* precede the existence of ISO WG21. Neither of the above applies to Qt header abuses, which (as Marc has noted) are trivially remedied by fixing a single header file in a single library distribution, and could have been as easily fixed on any day of the past 20+ years. What kind of argument is that? htons as a macro was worth considering, but the ones in Qt are not? Fixing the htons macro also "only requires changing one place" in the System C library. You are forgetting, that both changes break a huge amount of user code out there. And Qt’s macros have been around for about just as long (25 years), so they also *long* precede the existence of ISO WG21. Yes, there is a difference because Qt is not a system library, but it is nevertheless very widely used, so bringing the compatibility problem up as something to consider for the WG was certainly the right thing to do. Asking the ISO WG21 C++ Standard committee to compensate for one library's extended process failure is, at best, rude and foolish. I do agree that we should change this and get rid of the lower case macros. But blaming Qt here for keeping compatibility for our users while saying this is ok for system C libraries is just as rude. It would not be at all surprising if uses of all the other abused names--signals, slots, etc--show up in key components of C++23. Asking the committee to change them could not reasonably be expected to produce a peaceful outcome. The outcome of this last asking was plenty peaceful It is generally a mistake to confuse a polite but firm rejection with an invitation to dance. Marc's proposal is far too modest. Just change the default, in a single step: eliminate the abusive macros, as any responsible organization would have done *decades* ago. (An accompanying apology for past abuse would not be out of place.) Anybody who wants to keep using the abusive macros already knows how. They will also know that they are deliberately choosing to do The Wrong Thing. Why? The users of emit don't care it's a macro, and if they never use osyncstream, they don't run into this problem. Forcibly breaking their code without any sort of soft migration path doesn't seem like a user-friendly way to approach it. Ville is certainly aware of why common lower-case words as macros are ill-advised in public library headers. He is also aware that the ISO Standard C++ Library is not the only place where lower-case words are commonly used as properly-scoped identifiers. The world offers thousands of useful libraries, each equally or more subject to disruption by a single needlessly ill-disciplined library header. It is never the wrong time to step up and do the responsible thing. How often do we find that ten thousand bad choices, across decades, can be remedied by one good choice? This was one choice that Qt did 25 years ago, not ten thousand. And signals/slots was a great concept and at that time (and it did get picked up by many other frameworks). The lower case macros where also seen as the correct choice (they weren’t conflicting and it was common practice in many frameworks). Yes, we should maybe have used something else, but in hindsight those things are always easy to see and even easier to judge. I
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 4/13/20 3:41 PM, Ville Voutilainen wrote: On Mon, 13 Apr 2020 at 06:11, Nathan Myers wrote: The prevailing feeling in the room, when the vote was taken, was that Qt people MUST BE SMOKING CRACK if they think the ISO 14882 C++ Standard should or would tiptoe around Qt's aggressive abuse of lower-case macro names. That Qt has abused them for a long time makes the abuse exactly that much *less* excusable. To wit: you cannot claim you didn't know better. While the argument was indeed made that the prolonged time we have had lower-case macros in our public API makes accommodating them less appealing for WG21, the 'prevailing feeling' is something where you speak on behalf of a working group without the authority to do so, and it's highly questionable whether that feeling was as prevailing as you suggest. Neither does Ville have authority to speak on behalf of the Library Evolution Working Group. But Ville, Marc, and I are all well-equipped to interpret the (unusually large) number of "Strongly Against" votes cast in this instance. Sugar-coating the outcome of that vote benefits no one. The WG was firm but polite, this once. Expect greater firmness, and less politeness, next time. Take the hint. It also doesn't require smoking crack to suggest that WG21 considers code breakage due to new identifiers clashing with existing macros; they've done so before, when the Networking TS and its functions with names like ntohs and htons clashed with macros. Ville is certainly aware that the instance he cites involved macros that (a) commonly appear in vendor System C Library headers, from numerous sources, and (b) *long* precede the existence of ISO WG21. Neither of the above applies to Qt header abuses, which (as Marc has noted) are trivially remedied by fixing a single header file in a single library distribution, and could have been as easily fixed on any day of the past 20+ years. Asking the ISO WG21 C++ Standard committee to compensate for one library's extended process failure is, at best, rude and foolish. It would not be at all surprising if uses of all the other abused names--signals, slots, etc--show up in key components of C++23. Asking the committee to change them could not reasonably be expected to produce a peaceful outcome. The outcome of this last asking was plenty peaceful It is generally a mistake to confuse a polite but firm rejection with an invitation to dance. Marc's proposal is far too modest. Just change the default, in a single step: eliminate the abusive macros, as any responsible organization would have done *decades* ago. (An accompanying apology for past abuse would not be out of place.) Anybody who wants to keep using the abusive macros already knows how. They will also know that they are deliberately choosing to do The Wrong Thing. Why? The users of emit don't care it's a macro, and if they never use osyncstream, they don't run into this problem. Forcibly breaking their code without any sort of soft migration path doesn't seem like a user-friendly way to approach it. Ville is certainly aware of why common lower-case words as macros are ill-advised in public library headers. He is also aware that the ISO Standard C++ Library is not the only place where lower-case words are commonly used as properly-scoped identifiers. The world offers thousands of useful libraries, each equally or more subject to disruption by a single needlessly ill-disciplined library header. It is never the wrong time to step up and do the responsible thing. How often do we find that ten thousand bad choices, across decades, can be remedied by one good choice? Nathan Myers ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Mon, 13 Apr 2020 at 06:11, Nathan Myers wrote: > The prevailing feeling in the room, when the vote was taken, > was that Qt people MUST BE SMOKING CRACK if they think > the ISO 14882 C++ Standard should or would tiptoe around Qt's > aggressive abuse of lower-case macro names. That Qt has abused > them for a long time makes the abuse exactly that much *less* > excusable. To wit: you cannot claim you didn't know better. While the argument was indeed made that the prolonged time we have had lower-case macros in our public API makes accommodating them less appealing for WG21, the 'prevailing feeling' is something where you speak on behalf of a working group without the authority to do so, and it's highly questionable whether that feeling was as prevailing as you suggest. It also doesn't require smoking crack to suggest that WG21 considers code breakage due to new identifiers clashing with existing macros; they've done so before, when the Networking TS and its functions with names like ntohs and htons clashed with macros. > It would not be at all surprising if uses of all the other > abused names--signals, slots, etc--show up in key components > of C++23. Asking the committee to change them could not > reasonably be expected to produce a peaceful outcome. The outcome of this last asking was plenty peaceful. > Marc's proposal is far too modest. Just change the default, > in a single step: eliminate the abusive macros, as any > responsible organization would have done *decades* ago. > (An accompanying apology for past abuse would not be out of > place.) Anybody who wants to keep using the abusive macros > already knows how. They will also know that they are > deliberately choosing to do The Wrong Thing. Why? The users of emit don't care it's a macro, and if they never use osyncstream, they don't run into this problem. Forcibly breaking their code without any sort of soft migration path doesn't seem like a user-friendly way to approach it. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Fri, Feb 21, 2020 at 11:03:19PM +0200, Ville Voutilainen wrote: > On Fri, 21 Feb 2020 at 22:11, André Pönitz > > wrote: > > 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 Ville is demonstrating extreme courtesy, here, possibly to the detriment of the presentation of factual history. The prevailing feeling in the room, when the vote was taken, was that Qt people MUST BE SMOKING CRACK if they think the ISO 14882 C++ Standard should or would tiptoe around Qt's aggressive abuse of lower-case macro names. That Qt has abused them for a long time makes the abuse exactly that much *less* excusable. To wit: you cannot claim you didn't know better. It would not be at all surprising if uses of all the other abused names--signals, slots, etc--show up in key components of C++23. Asking the committee to change them could not reasonably be expected to produce a peaceful outcome. Marc's proposal is far too modest. Just change the default, in a single step: eliminate the abusive macros, as any responsible organization would have done *decades* ago. (An accompanying apology for past abuse would not be out of place.) Anybody who wants to keep using the abusive macros already knows how. They will also know that they are deliberately choosing to do The Wrong Thing. Nathan Myers ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 28 Feb 2020, at 21:33, Lars Knoll mailto:lars.kn...@qt.io>> wrote: So to shortcut this discussion a bit: I am completely opposed to a massive SIC changes/efforts for our signals (like giving them ugly names like emitClicked(), or signal objects). If people feel strongly, I am open to trying to find a way to keep some sort of ‘emit’ prefix (whether that’s Q_EMIT or a [[qt::emit]] attribute), but I do agree with Marc that we should in the long term try to get away from having emit/signals/slots defined as macros (at least by default). +1 but I hope we end up getting started on this “long term” project in some form. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 02/03/2020 16:42, Matthew Woehlke wrote: On 28/02/2020 15.33, Lars Knoll wrote: This is all nice and fun to bike shed about, but I don’t think those proposed solutions match the scope of the original problem (which was relatively small). I don’t think a massive source compatibility breakage is what we want, just because there is one std header using emit as a method name. I read this as: let's not do anything. With which I agree. And most of Qt’s signals are named in a way that makes it rather obvious it’s a signal we’re looking at (e.g. fooChanged() or clicked()), so there’s no need for an ‘emit’ in front to be clear. I don't see consensus here. On the contrary, the majority seems to feel that emit/Q_EMIT is useful. +1 André ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 28/02/2020 15.33, Lars Knoll wrote: > This is all nice and fun to bike shed about, but I don’t think those > proposed solutions match the scope of the original problem (which > was relatively small). I don’t think a massive source compatibility > breakage is what we want, just because there is one std header using > emit as a method name. I read this as: let's not do anything. With which I agree. > And most of Qt’s signals are named in a way that makes it rather > obvious it’s a signal we’re looking at (e.g. fooChanged() or > clicked()), so there’s no need for an ‘emit’ in front to be clear. I don't see consensus here. On the contrary, the majority seems to feel that emit/Q_EMIT is useful. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Monday, 2 March 2020 08:45:29 CET Jaroslaw Kobus wrote: > Allan Sandfeld Jensen (27 February 2020 23:03) replied: > > That is how I see it too. It essentially violates Qt code guidelines. If > > it > > was a normal method we would name it "emitEmptied()", so far we have just > > lived with "emit emptied()" instead. > > The issue is that if you want to emit a signal, "emitEmptied()" sounds OK, > while when you want to connect to it, you don't want to connect to > "emitEmptied", but to "emptied". > > Just my 4 cents (this amount wasn't offered in this thread, yet). > It came up. There was another suggestion that got around the problem: signalEmptied() it works because signal is both a noun and a verb :) 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Allan Sandfeld Jensen (27 February 2020 23:03) replied: > That is how I see it too. It essentially violates Qt code guidelines. If it > was a normal method we would name it "emitEmptied()", so far we have just > lived with "emit emptied()" instead. The issue is that if you want to emit a signal, "emitEmptied()" sounds OK, while when you want to connect to it, you don't want to connect to "emitEmptied", but to "emptied". Just my 4 cents (this amount wasn't offered in this thread, yet). Jarek From: Development on behalf of Edward Welbourne Sent: Friday, February 28, 2020 10:34 AM To: Allan Sandfeld Jensen Cc: development@qt-project.org Subject: Re: [Development] A modest proposal: disable lower-case keywords(emit, foreach, forever, signals, slots) by default On 26/02/2020 07.42, Tor Arne Vestbø wrote: >>> As others have argued, a signal is not special, in the sense that any >>> function can do anything, including emitting signals, so annotating it >>> doesn’t seem critical, as we apparently are fine without in all other >>> cases. On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote: >> Taking a step back... I think some of the reason for the current >> situation has to do with API design. Which of these is easier to understand? >> >> if (map.empty()) >> emptied(); >> >> - vs. - >> >> if (map.isEmpty()) >> emit emptied(); >> >> One reads like plain English. The other is missing words in a way that >> can confuse readers. Allan Sandfeld Jensen (27 February 2020 23:03) replied: > That is how I see it too. It essentially violates Qt code guidelines. If it > was a normal method we would name it "emitEmptied()", so far we have just > lived with "emit emptied()" instead. Indeed; most of the case for "emit" can be answered by a sensible naming convention. Even the case of "functions that trigger signals" can be handled by that, when it really matters. The only problem is that (as a legacy of having had a "keyword" for so long) we have a bunch of signals whose names don't conform to that convention. No-one has suggested we abolish "emit" overnight; so there shall be time to change the names of things during the course of the transition to retiring it. Eddy. ___ Development mailing list 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
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Fri, 28 Feb 2020 at 22:35, Lars Knoll wrote: > >> You'd see instead: > >>this->emptied().emit(...); > >>connect(foo, foo->emptied(), ...); > > I like this, then we could finally (and without hacks) have protected and > > private signals like in Qt 4. > > Would also solve the need for qOverload ? > This is all nice and fun to bike shed about, but I don’t think those proposed > solutions match the scope of the original problem (which was relatively > small). I don’t think a massive source compatibility breakage is what we > want, just because there is one std header using emit as a method name. > > And most of Qt’s signals are named in a way that makes it rather obvious it’s > a signal we’re looking at (e.g. fooChanged() or clicked()), so there’s no > need for an ‘emit’ in front to be clear. Some names are less obvious and the > ‘emit’ does help readability of our source code. > > So to shortcut this discussion a bit: I am completely opposed to a massive > SIC changes/efforts for our signals (like giving them ugly names like > emitClicked(), or signal objects). Just turning signals into objects seems SC to me. But nothing will be SC if it has the whole-token "emit" in it. So if we want to introduce some sort of a more-structured C++ approach, we need to pick a different name for it to coexist with emit. > If people feel strongly, I am open to trying to find a way to keep some sort > of ‘emit’ prefix (whether that’s Q_EMIT or a [[qt::emit]] attribute), but I > do agree with Marc that we should in the long term try to get away from > having emit/signals/slots defined as macros (at least by default). Agreed. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Friday, 28 February 2020 16:28:34 CET Matthew Woehlke wrote: > On 27/02/2020 17.03, Allan Sandfeld Jensen wrote: > > On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote: > >> On 26/02/2020 07.42, Tor Arne Vestbø wrote: > >>> As others have argued, a signal is not special, in the sense that any > >>> function can do anything, including emitting signals, so annotating it > >>> doesn’t seem critical, as we apparently are fine without in all other > >>> cases. > >> > >> Taking a step back... I think some of the reason for the current > >> situation has to do with API design. Which of these is easier to > >> understand?>> > >> if (map.empty()) > >> > >> emptied(); > >> > >> - vs. - > >> > >> if (map.isEmpty()) > >> > >> emit emptied(); > >> > >> One reads like plain English. The other is missing words in a way that > >> can confuse readers. > > > > That is how I see it too. It essentially violates Qt code guidelines. If > > it > > was a normal method we would name it "emitEmptied()", so far we have just > > lived with "emit emptied()" instead. > > I still have to disagree. *The signal* is "emptied". It is *not* > "emitEmptied". > > If we had to do it over again, it might make sense to follow Python and > make signals *objects* instead of *methods*. Then the code would look like: > > this->emptied.emit(...); > > But I *equally do not* want to write: > > connect(foo, ::emitEmptied, ...); I agree with the latter. We would need another syntax for connecting if the method names all began with emit. The old SIGNAL() macro could easily be adapted, but the modern syntax would be a problem. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Friday, 28 February 2020 12:12:35 PST Matthew Woehlke wrote: > On 28/02/2020 13.39, Thiago Macieira wrote: > > That's my point: it's a reasonable feature to ask that any good IDE > > implement. > It may be reasonable to ask *an IDE* to implement such a feature. It is > *not* reasonable to ask every place that developers look at code — some > of which don't even do basic syntax highlighting, much less have the > project parsing capability necessary to build a code model — to > implement such a feature. That being the case, you are never going to > achieve the same level of annotation as `emit` provides. We lived for 7 years with Gerrit not highlighting anything at all in qstring.cpp. That's not the end of the world. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Friday, 28 February 2020 12:06:06 PST Matthew Woehlke wrote:
> ...this might actually be better, since it would mean we still have MOC
> generating the code for the signal. (I was trying to figure out how MOC
> would generate the object initialization logic, and failing. I suspect
> this would work better. I wonder if we could even introduce this new
> style without breaking existing code source compatibility?)
>
> ...but I think connections would still look like either:
>
> connect(foo, ::emptied, ...);
>
> ...or:
>
> connect(foo->emptied(), ...);
Yes, this can be added BC break for new signals and is also SC forwards-
compatible ifor Qt 7:
template
class QSignal
{
...
};
static QSignal bytesWritten() const;
connect(foo, ::bytesWritten, receiver, ...);
Some magic in QObject::connect() can detect whether the return type is a
QSignal and so match the QSignal's template parameter to the slot, instead of
the PMF. It'll also call the static function to get the ID and this static
function is generated by moc. We could also design QSignal so it's a C++20
structural type, so it could eventually be used as a non-type template
parameter.
But it can't be retrofitted without BC break to existing signals, since the
function name is already used.
The signal emission would be different:
qEmit(::bytesWritten, count);
or
qEmit(q->bytesWritten(), count);
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> On 28 Feb 2020, at 21:18, Sérgio Martins via Development > wrote: > > On 2020-02-28 18:32, Thiago Macieira wrote: >> On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote: >>> If we had to do it over again, it might make sense to follow Python and >>> make signals *objects* instead of *methods*. Then the code would look like: >>> this->emptied.emit(...); >> Binary compatibility issue: if it's a member of the class, it can't be added >> or removed without changing the class's size and layout, so it would tie our >> hands for future improvements. >> You'd see instead: >>this->emptied().emit(...); >>connect(foo, foo->emptied(), ...); > > > I like this, then we could finally (and without hacks) have protected and > private signals like in Qt 4. > > Would also solve the need for qOverload ? This is all nice and fun to bike shed about, but I don’t think those proposed solutions match the scope of the original problem (which was relatively small). I don’t think a massive source compatibility breakage is what we want, just because there is one std header using emit as a method name. And most of Qt’s signals are named in a way that makes it rather obvious it’s a signal we’re looking at (e.g. fooChanged() or clicked()), so there’s no need for an ‘emit’ in front to be clear. Some names are less obvious and the ‘emit’ does help readability of our source code. So to shortcut this discussion a bit: I am completely opposed to a massive SIC changes/efforts for our signals (like giving them ugly names like emitClicked(), or signal objects). If people feel strongly, I am open to trying to find a way to keep some sort of ‘emit’ prefix (whether that’s Q_EMIT or a [[qt::emit]] attribute), but I do agree with Marc that we should in the long term try to get away from having emit/signals/slots defined as macros (at least by default). Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 2020-02-28 18:32, Thiago Macieira wrote: On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote: If we had to do it over again, it might make sense to follow Python and make signals *objects* instead of *methods*. Then the code would look like: this->emptied.emit(...); Binary compatibility issue: if it's a member of the class, it can't be added or removed without changing the class's size and layout, so it would tie our hands for future improvements. You'd see instead: this->emptied().emit(...); connect(foo, foo->emptied(), ...); I like this, then we could finally (and without hacks) have protected and private signals like in Qt 4. Would also solve the need for qOverload ? Regards, -- Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 28/02/2020 13.39, Thiago Macieira wrote: > That's my point: it's a reasonable feature to ask that any good IDE implement. It may be reasonable to ask *an IDE* to implement such a feature. It is *not* reasonable to ask every place that developers look at code — some of which don't even do basic syntax highlighting, much less have the project parsing capability necessary to build a code model — to implement such a feature. That being the case, you are never going to achieve the same level of annotation as `emit` provides. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 28/02/2020 13.37, Konstantin Tokarev wrote: > 28.02.2020, 21:34, "Thiago Macieira" : >> On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote: >>> If we had to do it over again, it might make sense to follow Python and >>> make signals *objects* instead of *methods*. Then the code would look like: >>> >>> this->emptied.emit(...); >> >> Binary compatibility issue: if it's a member of the class, it can't be added >> or removed without changing the class's size and layout, so it would tie our >> hands for future improvements. >> >> You'd see instead: >> >> this->emptied().emit(...); >> connect(foo, foo->emptied(), ...); > > I think it could be a static member as well - there is no real reason for > such member > to be per-instance in the first place. If it was static, you'd have to pass the instance to `emit(...)`. Otherwise you don't know what instance sent the signal. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 28/02/2020 13.32, Thiago Macieira wrote: > On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote: >> If we had to do it over again, it might make sense to follow Python and >> make signals *objects* instead of *methods*. Then the code would look like: >> >> this->emptied.emit(...); > > Binary compatibility issue: if it's a member of the class, it can't be added > or removed without changing the class's size and layout, so it would tie our > hands for future improvements. Good point. Although... > You'd see instead: > > this->emptied().emit(...); > connect(foo, foo->emptied(), ...); ...this might actually be better, since it would mean we still have MOC generating the code for the signal. (I was trying to figure out how MOC would generate the object initialization logic, and failing. I suspect this would work better. I wonder if we could even introduce this new style without breaking existing code source compatibility?) ...but I think connections would still look like either: connect(foo, ::emptied, ...); ...or: connect(foo->emptied(), ...); -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Friday, 28 February 2020 07:24:32 PST Matthew Woehlke wrote:
> We aren't talking about recognizing `emit`. We're talking about being
> able to inspect the following code:
>
> if (...)
> {
> this->update();
> this->changed();
> }
>
> ...and recognizing that the former is a "regular" method call, while the
> latter is a signal emission. Which requires a code model that correctly
> identifies the corresponding header *and* understands MOC's
> meta-language. TTBOMK, *no* IDE's (or perhaps only QtC) currently do the
> latter.
That's my point: it's a reasonable feature to ask that any good IDE implement.
Qt is not an irrelevant chunk of C++, so understanding what a signal is and
helping developers is very much in an IDE's scope. At the very least, they
should have a feature to detect whether the function being called is code in
this project, another project, or is generated during the build.
Whether the feature will be implemented is a whole other story. But it's
reasonable to ask.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
28.02.2020, 21:34, "Thiago Macieira" : > On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote: >> If we had to do it over again, it might make sense to follow Python and >> make signals *objects* instead of *methods*. Then the code would look like: >> >> this->emptied.emit(...); > > Binary compatibility issue: if it's a member of the class, it can't be added > or removed without changing the class's size and layout, so it would tie our > hands for future improvements. > > You'd see instead: > > this->emptied().emit(...); > connect(foo, foo->emptied(), ...); I think it could be a static member as well - there is no real reason for such member to be per-instance in the first place. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote: > If we had to do it over again, it might make sense to follow Python and > make signals *objects* instead of *methods*. Then the code would look like: > > this->emptied.emit(...); Binary compatibility issue: if it's a member of the class, it can't be added or removed without changing the class's size and layout, so it would tie our hands for future improvements. You'd see instead: this->emptied().emit(...); connect(foo, foo->emptied(), ...); -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 27/02/2020 17.03, Allan Sandfeld Jensen wrote: > On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote: >> On 26/02/2020 07.42, Tor Arne Vestbø wrote: >>> As others have argued, a signal is not special, in the sense that any >>> function can do anything, including emitting signals, so annotating it >>> doesn’t seem critical, as we apparently are fine without in all other >>> cases. >> Taking a step back... I think some of the reason for the current >> situation has to do with API design. Which of these is easier to understand? >> >> if (map.empty()) >> emptied(); >> >> - vs. - >> >> if (map.isEmpty()) >> emit emptied(); >> >> One reads like plain English. The other is missing words in a way that >> can confuse readers. > > That is how I see it too. It essentially violates Qt code guidelines. If it > was a normal method we would name it "emitEmptied()", so far we have just > lived with "emit emptied()" instead. I still have to disagree. *The signal* is "emptied". It is *not* "emitEmptied". If we had to do it over again, it might make sense to follow Python and make signals *objects* instead of *methods*. Then the code would look like: this->emptied.emit(...); But I *equally do not* want to write: connect(foo, ::emitEmptied, ...); -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 27/02/2020 17.01, Allan Sandfeld Jensen wrote:
> On Thursday, 27 February 2020 21:43:33 CET Matthew Woehlke wrote:
>> On 27/02/2020 13.57, Thiago Macieira wrote:
>>> On Monday, 24 February 2020 03:30:25 PST André Somers wrote:
You seem to assume everyone used QtCreator as their IDE of choice. That
is
not a reasonable assumption I think.
>>>
>>> It is a reasonable feature request for ALL IDEs to understand what a Qt
>>> signal is.
>>
>> Really? You include github/gitlab/phabricator in that list? Vim? Notepad++?
>
> I would be surprised if any of those didn't.
Really? Because only one of those *might* include code parsing abilities.
We aren't talking about recognizing `emit`. We're talking about being
able to inspect the following code:
if (...)
{
this->update();
this->changed();
}
...and recognizing that the former is a "regular" method call, while the
latter is a signal emission. Which requires a code model that correctly
identifies the corresponding header *and* understands MOC's
meta-language. TTBOMK, *no* IDE's (or perhaps only QtC) currently do the
latter.
Conversely, `emit` works *even in non-IDE's*; notepad, cat, grep,
(github), etc Claiming that "the IDE can do just as good a job
marking signals as using `emit`" is just plain wrong, or at least,
missing the point.
--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Fri, 28 Feb 2020 at 10:35, Edward Welbourne wrote: > > > Indeed; most of the case for "emit" can be answered by a sensible naming > convention. > One case where it does not work is in connections. emit somethingWasDone() and emitSomethingWasDone() look similar. But the emit in connect(obj, ::emitSomethingWasDone, ...) looks a bit superfluous to me. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 26/02/2020 07.42, Tor Arne Vestbø wrote: >>> As others have argued, a signal is not special, in the sense that any >>> function can do anything, including emitting signals, so annotating it >>> doesn’t seem critical, as we apparently are fine without in all other >>> cases. On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote: >> Taking a step back... I think some of the reason for the current >> situation has to do with API design. Which of these is easier to understand? >> >> if (map.empty()) >> emptied(); >> >> - vs. - >> >> if (map.isEmpty()) >> emit emptied(); >> >> One reads like plain English. The other is missing words in a way that >> can confuse readers. Allan Sandfeld Jensen (27 February 2020 23:03) replied: > That is how I see it too. It essentially violates Qt code guidelines. If it > was a normal method we would name it "emitEmptied()", so far we have just > lived with "emit emptied()" instead. Indeed; most of the case for "emit" can be answered by a sensible naming convention. Even the case of "functions that trigger signals" can be handled by that, when it really matters. The only problem is that (as a legacy of having had a "keyword" for so long) we have a bunch of signals whose names don't conform to that convention. No-one has suggested we abolish "emit" overnight; so there shall be time to change the names of things during the course of the transition to retiring it. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Monday, 24 February 2020 03:30:25 PST André Somers wrote: You seem to assume everyone used QtCreator as their IDE of choice. That is not a reasonable assumption I think. On 27/02/2020 13.57, Thiago Macieira wrote: >>> It is a reasonable feature request for ALL IDEs to understand what a >>> Qt signal is. On Thursday, 27 February 2020 21:43:33 CET Matthew Woehlke wrote: >> Really? You include github/gitlab/phabricator in that list? Vim? >> Notepad++? Allan Sandfeld Jensen (27 February 2020 23:01) replied > I would be surprised if any of those didn't. I see that emacs in fact colours emit green and the next word yellow (I think it's mistaking it for a declaration, as it colours types green and identifiers yellow in those), but if I remove emit it doesn't do anything special with the signal invocation. So I think that counts as emacs not knowing what signals are, although it does do something, albeit probably bogus, with the "keyword" when used. Whether one counts emacs, vim or notepad++ as an IDE is, however, another story ! I read Thiago as talking about things that *call themselves* IDEs, rather than text editors. Even so, asking MSVS to support Qt-specific features ... sounds ambitious - good luck ;^> Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote: > On 26/02/2020 07.42, Tor Arne Vestbø wrote: > > As others have argued, a signal is not special, in the sense that any > > function can do anything, including emitting signals, so annotating it > > doesn’t seem critical, as we apparently are fine without in all other > > cases. > Taking a step back... I think some of the reason for the current > situation has to do with API design. Which of these is easier to understand? > > if (map.empty()) > emptied(); > > - vs. - > > if (map.isEmpty()) > emit emptied(); > > One reads like plain English. The other is missing words in a way that > can confuse readers. That is how I see it too. It essentially violates Qt code guidelines. If it was a normal method we would name it "emitEmptied()", so far we have just lived with "emit emptied()" instead. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Thursday, 27 February 2020 21:43:33 CET Matthew Woehlke wrote: > On 27/02/2020 13.57, Thiago Macieira wrote: > > On Monday, 24 February 2020 03:30:25 PST André Somers wrote: > >> You seem to assume everyone used QtCreator as their IDE of choice. That > >> is > >> not a reasonable assumption I think. > > > > It is a reasonable feature request for ALL IDEs to understand what a Qt > > signal is. > > Really? You include github/gitlab/phabricator in that list? Vim? Notepad++? I would be surprised if any of those didn't. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 26/02/2020 09.10, Oliver Wolff wrote: > For me the emit has value. It's just an annotation, but for me it > serves a purpose. I can see that this is a signal emission and even > if people keep arguing that this is pointless it serves a purpose to > me. "Look here a signal is emitted, so that other parts who are > interested in this information might react". For me that's important > information when reading code (be it while coding or in code > reviews). Another point that I don't think has been mentioned... however much you want to argue about functions being able to do anything, the fact remains that signals/slots are distinct enough from simply calling functions as to be noteworthy... and an annotation makes it dead simple to *find* every place where *any* signal is being emitted. Take away the annotation, and you have to search for individual signals. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 26/02/2020 07.42, Tor Arne Vestbø wrote: > As others have argued, a signal is not special, in the sense that any > function can do anything, including emitting signals, so annotating it > doesn’t seem critical, as we apparently are fine without in all other cases. Taking a step back... I think some of the reason for the current situation has to do with API design. Which of these is easier to understand? if (map.empty()) emptied(); - vs. - if (map.isEmpty()) emit emptied(); One reads like plain English. The other is missing words in a way that can confuse readers. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 27/02/2020 13.57, Thiago Macieira wrote: > On Monday, 24 February 2020 03:30:25 PST André Somers wrote: >> You seem to assume everyone used QtCreator as their IDE of choice. That is >> not a reasonable assumption I think. > > It is a reasonable feature request for ALL IDEs to understand what a Qt > signal > is. Really? You include github/gitlab/phabricator in that list? Vim? Notepad++? -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Thursday, 27 February 2020 04:40:34 PST Ville Voutilainen wrote: > The chance is very good; I talked about this with the maintainer of > GCC already, and he was amenable to disabling > an "unknown attribute" warning if the attribute has a namespace. For > attributes that don't have namespaces, > diagnosing unknown attributes allows diagnosing typos, so it's > unlikely that all such warnings would be axed. I think what we need is an attribute-declaring attribute. That way, the compiler can still warn about unknown attributes in case they are typos, but won't for attributes that the user intended to write. [[declare_attribute(qt::emit)]]; later: [[qt::emit]] closed(); This is a standard change. Alternatively, [[gnu::declare_attribute(qt::emit)]] until C++23. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Wednesday, 26 February 2020 08:26:14 PST Alex Blasche wrote: > > fooChanged(), and can perfectly well stand on their own, without > > annotations. Corner cases like "emit pressed();” can be annotated with > > Q_EMIT or a comment to make it clearer what’s going on. > > > Some end with "Changed". The overwhelming amount does not follow this rule > and we won't change the naming for Qt 6 either. The naming convention > merely states that there is a verb at the end. No, but the vast majority does have a verb in the past tense as its core name component and that's enforced by our API design rules. Only a few legacy signals like readyRead() aren't like that. $ grep -A1 '// SIGNAL' **/.moc/*(.) | \ sed -En 's/.*-void .*::([a-zA-Z0-9_]+)\(.*/\1/p' | \ grep -v Changed | sort -u abortHttpRequest aboutToActivate aboutToBeDestroyed aboutToBlock aboutToClose aboutToCompose aboutToDestroyContext aboutToHide aboutToQuit aboutToResize aboutToShow aboutToSuspend accept accepted acceptError ActionInvoked actionTriggered activate activated activatedAmbiguously activationFinished AddAccessible anchorClicked attention authenticationRequired Available awake backwardAvailable beforeDelete beforeInsert beforeUpdate blockMarkerHovered buttonClicked buttonPressed buttonReleased buttonToggled bytesWritten cacheCredentials callWithCallbackFailed canceled cellActivated cellClicked cellDoubleClicked cellEntered cellPressed changed changeDate channelBytesWritten channelReadyRead clicked closed closeEditor collapsed colorDropped colorSelected columnsAboutToBeInserted columnsAboutToBeMoved columnsAboutToBeRemoved columnsInserted columnsMoved columnsRemoved commandFinished commandStarted commitData commitDataRequest CommitText configurationAdded configurationRemoved configurationUpdateComplete connected connectionError connectionRequested connectionsListReady connectState contentsChange contextMenuRequested copyAvailable CursorDownLookupTable cursorPositionChangeRequested CursorUpLookupTable customButtonClicked customContextMenuRequested dataReadProgress dataSendProgress dataTransferProgress DeleteSurroundingText destroyed deviceAdded deviceDetected deviceRemoved devicesListReady directoryEntered directoryLoaded directoryUrlEntered Disabled disconnected done doScroll doubleClicked doubleValueSelected downloadData downloadFinished downloadMetaData downloadProgress editingFinished Enabled encrypted encryptedBytesWritten entered entryReady error errorOccurred exited expanded fileRenamed fileSelected filesSelected filterSelected finished finishedWithError fontSelected forcedSessionClose forwardAvailable ForwardKeyEvent frameGrabbed frameSwapped goToUrl gripMoved handleMouseEvent handleWheelEvent handshakeTimeout haveUploadData headerRead helpRequested HideAuxiliaryText HideLookupTable HidePreeditText hidingCalendar highlighted hostFound hovered indexesMoved inputRejected interrupted intValueSelected itemActivated ItemActivationRequested itemClicked itemCollapsed itemDoubleClicked itemEntered itemExpanded itemPressed itemsAvailable itemSelected itemsInvalidated itemsMissing ItemsPropertiesUpdated itemsUpdated lastWindowClosed LayoutUpdated linkActivated linkHovered listInfo locked mapped messageClicked messageLogged messageNeedsSending modelAboutToBeReset modelReset NameAcquired NameLost nameResolved networkSessionConnected NewAttentionIcon newCol newConfigurationActivated newConnection newDateSelected newHsv NewIcon newListOfFiles NewMenu NewOverlayIcon newServerConnection NewStatus NewTitle NewToolTip notification NotificationClosed opened overflow pageAdded PageDownLookupTable pageRemoved PageUpLookupTable paintRequested paused peerVerifyError popupRequested preSharedKeyAuthenticationRequired pressed primeInsert processedData propertiesAssigned propertiesReady propertiesUpdated proxyAuthenticationRequired pskRequired _q_clicked _q_close _q_doubleClicked _q_minimize _q_restore quitPendingWaitsForOpened rawCommandReply rawFtpReply readBufferFreed readChannelFinished readProgress readyRead readyReadStandardError readyReadStandardOutput redirectAllowed redirected redoAvailable RegisterProperties reject rejected released RemoveAccessible removed reply RequireSurroundingText resetButton resetData resetInputContext resized resultReadyAt resultsReady resultsReadyAt resumed returnPressed rowsAboutToBeInserted rowsAboutToBeMoved rowsAboutToBeRemoved rowsAdded rowsInserted rowsMoved rowsRemoved saveStateRequest scanFinished screenAdded screenRemoved sectionClicked sectionDoubleClicked sectionEntered sectionHandleDoubleClicked sectionMoved sectionPressed sectionResized selected serverRequested serviceRegistered servicesReady serviceUnregistered settingsReady ShowAuxiliaryText showDate ShowLookupTable ShowPreeditText sliderMoved sliderPressed sliderReleased splitterMoved spyHooksFinished sslErrors started startHttpRequest startHttpRequestSynchronously stopped subWindowActivated tabBarClicked tabBarDoubleClicked
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Monday, 24 February 2020 03:30:25 PST André Somers wrote: > > 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. It’s also safer, as the > > keyword can be forgotten or applied to the wrong places. > > You seem to assume everyone used QtCreator as their IDE of choice. That is > not a reasonable assumption I think. It is a reasonable feature request for ALL IDEs to understand what a Qt signal is. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Tuesday, 25 February 2020 23:24:14 PST Lars Knoll wrote: > The way it works is that in case more than one slot is connected to such a > signal, the return value of the last slot connected is returned, if nothing > is connected a default constructed value is returned. The last DirectConnection slot connected. I don't think the functionality was hooked up after BlockingQueuedConnection was added, but it cannot work with regular QueuedConnection. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> I may need to write that patch myself.
Would you consider instead a patch introducing a builtin that allows a
library to declare attributes they "support" ?
eg something in the taste of __builtin_declare_valid_attribute("qt::emit");
A far cry from attribute creation abilities of languages such as C#[1] or
Java but
better than nothing.
This way typo detection could happen with [[qt::emitt]] for instance (or
more likely people trying [[Qt::emit]] or [[QT::emit]]).
Best,
Jean-Michaël
[1]:
https://docs.microsoft.com/en-us/dotnet/standard/attributes/writing-custom-attributes
On Thu, Feb 27, 2020 at 1:41 PM Ville Voutilainen <
ville.voutilai...@gmail.com> wrote:
> On Thu, 27 Feb 2020 at 09:15, Alex Blasche
> wrote:
>
> > >In general, implementations can still warn about pretty much whatever
> > >they please, especially considering
> > >that their default modes are not strictly conforming.
> > >
> > >The compilers we plan to support in Qt 6 do warn about unknown
> > >attributes, so the allowance point is kinda
> > >theoretical.
> >
> > Ville, please help me understand sth. If the express intention of
> attributes is that users should be encouraged to have their own, aren't the
> warning policies exhibited by current compilers counter productive to the
> intent of their intended purpose? Or do attributes mostly exist for the
> purposes compilers themselves may face?
>
> They are counter-productive, yes. The compilers overreach, see below.
>
> > Also what's the chance that compiler communities might accept Qt
> specific attributes if for example TQtC were to put relevant patches
> forward?
>
> The chance is very good; I talked about this with the maintainer of
> GCC already, and he was amenable to disabling
> an "unknown attribute" warning if the attribute has a namespace. For
> attributes that don't have namespaces,
> diagnosing unknown attributes allows diagnosing typos, so it's
> unlikely that all such warnings would be axed.
>
> I may need to write that patch myself. In any case, such solutions
> don't help GCC 9.x users or users of earlier
> GCC 10.x versions, in case the patch wouldn't hit GCC 10.
>
> I think the chance of success is similarly good with clang; the case
> for not complaining about namespaced
> attributes is fairly clear. But that change isn't something I have
> time to patch into clang. I haven't looked at
> MSVC or other compilers.
> ___
> Development mailing list
> 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
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Thu, 27 Feb 2020 at 09:15, Alex Blasche wrote: > >In general, implementations can still warn about pretty much whatever > >they please, especially considering > >that their default modes are not strictly conforming. > > > >The compilers we plan to support in Qt 6 do warn about unknown > >attributes, so the allowance point is kinda > >theoretical. > > Ville, please help me understand sth. If the express intention of attributes > is that users should be encouraged to have their own, aren't the warning > policies exhibited by current compilers counter productive to the intent of > their intended purpose? Or do attributes mostly exist for the purposes > compilers themselves may face? They are counter-productive, yes. The compilers overreach, see below. > Also what's the chance that compiler communities might accept Qt specific > attributes if for example TQtC were to put relevant patches forward? The chance is very good; I talked about this with the maintainer of GCC already, and he was amenable to disabling an "unknown attribute" warning if the attribute has a namespace. For attributes that don't have namespaces, diagnosing unknown attributes allows diagnosing typos, so it's unlikely that all such warnings would be axed. I may need to write that patch myself. In any case, such solutions don't help GCC 9.x users or users of earlier GCC 10.x versions, in case the patch wouldn't hit GCC 10. I think the chance of success is similarly good with clang; the case for not complaining about namespaced attributes is fairly clear. But that change isn't something I have time to patch into clang. I haven't looked at MSVC or other compilers. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 15.2.2020 16.23, Marc Mutz via Development wrote: > Hi, > > C++20 will contain new classes with emit() member functions > (wg21.link/P0053). While that will only pose problems for users that > include the new header after (almost) any Qt header, this > should serve as a second shot across the bows (after namespace > boost::signals) that we should change something. This serves as proof that our custom keywords cause issues occasionally, but combined use of and Qt won't be that common. > > To that effect, I'd like to propose that we switch the default for > QT_NO_KEYWORDS around. I'd so this in three phases: > > 1. phase > a. Add CONFIG += keywords (or the CMake equivalent) to act as an > antagonist for no_keywords. > b. Change the documentation, examples and Qt implementation to use the > Q_ macros > > In this case, they just cancel each other out. This is just so you can > already express the intent to continue to use lowercase keywords by > saying CONFIG += keywords. It also makes sure that next generation of Qt > programmers grows up with the Q_ macros, so they don't squint their eyes > when they see > > Q_EMIT valueChanged(m_value); > > 2. phase > a. Make no_keywords the default > b. Change the documentation accordingly > c. the QT_NO_KEYWORDS macro is left untouched > > In this phase, projects that use qmake (or by some other means inherit > Qt's default) > > 3. phase > a. Replace QT_NO_KEYWORDS with a new macro QT_USE_KEYWORDS (or somesuch). > b. Change the documentation accordingly > > In this phase, even projects using not using Qt's defaults would switch > defaults. This plan requires everyone to drop the use of our custom keywords in their code or to enable a new define to compile source code that worked previously. As a backward-incompatible change I think it needs a strong justification. A couple of conflicts during 20 years that can be resolved with equivalent effort (QT_NO_EMIT or QT_NO_KEYWORDS) but are only encountered pretty rarely don't seem like a strong enough reasons to me. Isn't the way to cause the least pain for our users to do nothing in this case? The effort seems to be the same, it's just whether we impose it on everyone or just the people encountering conflicts. The rest of the thread has had a lot of discussion on what the possible alternatives to annotating signal emissions could be or whether such a thing is necessary at all. But I think evaluating whether this warrants a move at all should be considered more than it has. Alternatives may not be relevant if we're not going to get rid of `emit` being defined by default. > > We can then stop there, or we use the years to come to decide how we > want to transition off the macro stuff and consult with ISO C++ so they > can work with us to give us the functionality to do so (meta-classes, > qt::emit with overloaded whitespace operator, whatever). > > I think it's clear that, as it is now, where for two years such a > problem exists in the IS and doesn't get detected by "the Qt project", > for a certain definition thereof, and only comes up by chance encounter > at the last day of the last meeting before C++20 is "done", it cannot > continue. Or, if it continues, Qt will be bitten more and more by stuff > ISO C++ does. If ISO C++'s estimate for C++ programmers and TQC's claim > for Qt developers are both correct, we're looking at a size of the > intersection of the two groups of over 20% of all C++ programmers. I > happen to be firmly rooted in both, and I'd be sad to see the two > separate ways even more than they have done in the past. We should co-operate better in the future. We definitely should *not* add any new custom keywords. But is it worth tackling something very common that causes problems relatively rarely? -- Kari ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
From: Development on behalf of Ville Voutilainen On Wed, 26 Feb 2020 at 18:45, Benjamin TERRIER wrote: >> I would like the idea of using attributes for this. However, compilers are >> allowed to warn for unknown attributes, which is useful to detect typos. >> This means that we would get a warning for each usage of [[qt::emit]]. So >> unless there is a way to disable unknown attribute warnings for a specific >> set of custom attributes this will be a pain. >That's debatable. [dcl.attr]/6 says >Any attribute-token that is not recognized by the implementation is ignored. >In general, implementations can still warn about pretty much whatever >they please, especially considering >that their default modes are not strictly conforming. > >The compilers we plan to support in Qt 6 do warn about unknown >attributes, so the allowance point is kinda >theoretical. Ville, please help me understand sth. If the express intention of attributes is that users should be encouraged to have their own, aren't the warning policies exhibited by current compilers counter productive to the intent of their intended purpose? Or do attributes mostly exist for the purposes compilers themselves may face? Also what's the chance that compiler communities might accept Qt specific attributes if for example TQtC were to put relevant patches forward? -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Wed, 26 Feb 2020 at 18:45, Benjamin TERRIER wrote: > I would like the idea of using attributes for this. However, compilers are > allowed to warn for unknown attributes, which is useful to detect typos. > This means that we would get a warning for each usage of [[qt::emit]]. So > unless there is a way to disable unknown attribute warnings for a specific > set of custom attributes this will be a pain. That's debatable. [dcl.attr]/6 says Any attribute-token that is not recognized by the implementation is ignored. In general, implementations can still warn about pretty much whatever they please, especially considering that their default modes are not strictly conforming. The compilers we plan to support in Qt 6 do warn about unknown attributes, so the allowance point is kinda theoretical. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
26.02.2020, 19:28, "Alex Blasche" : >> Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø: >> > We don’t need one rule to rule them all either. Many signals are named >> fooChanged(), and can perfectly well stand on their own, without >> annotations. >> Corner cases like "emit pressed();” can be annotated with Q_EMIT or a >> comment >> to make it clearer what’s going on. > > Some end with "Changed". The overwhelming amount does not follow this rule > and we won't change the naming for Qt 6 either. The naming convention merely > states that there is a verb at the end. For example, let's consider QAbstractButton::clicked() signal. There is no sense in renaming it to anything ending with "Changed". -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Fri, 21 Feb 2020 at 09:24, Kai Köhne wrote: > Hi, > > Another alternative is to actually use C++ attributes for this: > > [[qt::emit]] somethingChanged(); > > C++ attributes are required since C++11, and since C++17 the compiler is > also required to just ignore one's it doesn't know [1]. Because it is part > of the core language, It is also something every C++ IDE and tool does > accept (and could even check for) ... > I would like the idea of using attributes for this. However, compilers are allowed to warn for unknown attributes, which is useful to detect typos. This means that we would get a warning for each usage of [[qt::emit]]. So unless there is a way to disable unknown attribute warnings for a specific set of custom attributes this will be a pain. My 2 cents Benjamin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> -Original Message- > From: Lars Knoll > >> -Original Message- > >> From: Lars Knoll > I’m not trying to make this only about emit. But it’s the concrete > problem we’re facing now, and emit is IMO the one keyword where we > simply don’t need a replacement because it has no real semantic > meaning in > >> C++. > >>> > >>> I don't think semantics matter here. It is all about annotation and > readability. > >> With the same arguments we design APIs. While Kai's survey is > >> inconclusive about the actual solution, it is conclusive in one > >> aspect. There is a clear majority to have sth in place for > annotation/readability purposes. > >> > >> As Kai said, in this case a comment would do the trick just as well, > >> no need for a keyword or macro: > >> > >> /*emit*/ mySignal(); or > >> mySignal(); // emit > > > > Can you see us adopting a coding style that enforces the use of such > comments? Otherwise this will quickly change to comments being forgotten > which makes the above suggestion less valuable. Although the alternatives have > no semantics either they impress a stronger coding style than comments IMO. > > We’re neither enforcing the use of ‘emit’ currently. And I honestly find most > of > the alternatives to be worse than no annotation at all. Lars, I did not talk about enforcing. It is a fact that we overwhelmingly use it today. That's a convention hammered into each of our heads by years of adherence. Your comment suggestion would not have that unspoken benefit and therefore extremely quickly disappear. Please let me ask again, can you consider a coding convention to use such comments? Normally the usage of systematic comments for annotation is extremely rare. Therefore, I cannot see that your suggestion to adopt a comment style annotation would be anything else but a lip service without such a convention. -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> -Original Message- > From: Development On Behalf Of > Simon Hausmann Please don't generalise where there is no general or even majority count (see below). > Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø: > > We don’t need one rule to rule them all either. Many signals are named > fooChanged(), and can perfectly well stand on their own, without annotations. > Corner cases like "emit pressed();” can be annotated with Q_EMIT or a comment > to make it clearer what’s going on. Some end with "Changed". The overwhelming amount does not follow this rule and we won't change the naming for Qt 6 either. The naming convention merely states that there is a verb at the end. > This is also what tipped me over. We have stronger conventions nowadays with > property based APIs and the Changed suffix for the corresponding signals. > We'll > be fine without "emit" :-) Another case of generalisation where there is none. QML may have that notation but C++ doesn't. Now I don't know whether you plan to enforce such a rule for the new object property system but I would argue forcing every object property signal to end with "Changed" might be a bit too much. Last but not least, not every signal is associated to a property either. -- Alex > ___ > Development mailing list > 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
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 2/15/20 3:23 PM, Marc Mutz via Development wrote: > Hi, > > C++20 will contain new classes with emit() member functions > (wg21.link/P0053). > Hello, I know this discussion is about C++, but I just wanted to mention that Signals in Python are objects, and we rely on the emit method to emit signals (duh!). As a C++ programmer, renaming the emit macro for something else doesn't affect me, even if we decide to remove it, because I think we can do fine, so I have no strong feelings. As a Python programmer, removing the macro will cause headaches when trying to figure out how to make Signals work, since looking at some random Qt/C++ code I will not know what's the proper way of emitting one. (In case I'm not aware of these conventions) As a PySide developer, if we agree to change the name, we can just rename the function we expose, to qEmit or whatever, but in case the macro gets removed, we will need to keep the emit() method, and explain to users that in C++ land this doesn't exists, which will maybe cause some headaches. My 3 cents, Cheers PS: More info about signals and slots in PySide: https://wiki.qt.io/Qt_for_Python_Signals_and_Slots -- Dr. Cristian Maureira-Fredes R Manager The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin 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
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Oliver Wolff (26 February 2020 15:10) wrote [snip] > it serves a purpose to me. "Look here a signal is emitted, so that other > parts who are interested in this information might react". For me that's > important information when reading code (be it while coding or in code > reviews). Indeed. As a reviewer, the awareness that "this" may have been destroyed at the emit makes these lines a significant pause for thought. Admittedly, when the emit happens inside some method I'm calling, that may be hidden; but then that method's name should reflect the possibly drastic changes to context that are credible responses to its signalling. We can say the same of the signal name, of course, but the signal itself is somewhat "atomic" where the methods that exercise them are (ipso facto) composites whose names need to reflect what they're expected to do over-all, where the signal's name properly just says what event has happened, that someone might want to connect to. I'd consider a naming convention adequate for signals, all the same. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Hi, On 21/02/2020 13:57, Mitch Curtis wrote: >> -Original Message- >> From: Eike Ziller >> Sent: Friday, 21 February 2020 1:55 PM >> To: Mitch Curtis >> Cc: Ville Voutilainen ; Alex Blasche >> ; 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 13:30, Mitch Curtis wrote: >>> >>>> -Original Message- >>>> From: Development On Behalf >> Of >>>> Ville Voutilainen >>>> Sent: Friday, 21 February 2020 12:16 PM >>>> To: Alex Blasche >>>> Cc: development@qt-project.org >>>> Subject: Re: [Development] A modest proposal: disable lower-case >>>> keywords (emit, foreach, forever, signals, slots) by default >>>> >>>> On Fri, 21 Feb 2020 at 10:42, Alex Blasche >> wrote: >>>>> I think a fallback to >>>>> >>>>> somethingChanged() >>>>> >>>>> 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. >> >> It isn’t because you can put “emit” anywhere in your code because it has no >> semantics for the compiler. > > I never said it had any semantic purpose, I'm purely arguing that it has > implications for readability. I agree with Mitch here. For me the emit has value. It's just an annotation, but for me it serves a purpose. I can see that this is a signal emission and even if people keep arguing that this is pointless it serves a purpose to me. "Look here a signal is emitted, so that other parts who are interested in this information might react". For me that's important information when reading code (be it while coding or in code reviews). Now everyone can tell me, that I am stupid and that is not necessary, but to me it looks, like people are jumping the "I agree" train and people who disagree are somewhat "intimidated" and do no longer dare to voice that. My 5 cents, Olli > >> It’s not beter than any code comment that you could also put there, like >> >> /*emit*/ something(); >> >> or >> >> something(); // emit > > I disagree; I think those are ugly. > >>> Not all signals follow the *Changed() naming convention, nor should they, >> so it becomes even less obvious in those cases. >>> >>>> ___ >>>> Development mailing list >>>> 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 > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
26.02.2020, 16:34, "Simon Hausmann" : > Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø: >>> We’re neither enforcing the use of ‘emit’ currently. And I honestly find >>> most of the alternatives to be worse than no annotation at all. >> I agree. >> >> As others have argued, a signal is not special, in the sense that any >> function can do anything, including emitting signals, so annotating it >> doesn’t seem critical, as we apparently are fine without in all other cases. >> >> We don’t need one rule to rule them all either. Many signals are named >> fooChanged(), and can perfectly well stand on their own, without >> annotations. Corner cases like "emit pressed();” can be annotated with >> Q_EMIT or a comment to make it clearer what’s going on. > > This is also what tipped me over. We have stronger conventions nowadays > with property based APIs and the Changed suffix for the corresponding > signals. We'll be fine without "emit" :-) FWIW, not all signals in world have corresponding properties. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø: >> We’re neither enforcing the use of ‘emit’ currently. And I honestly find >> most of the alternatives to be worse than no annotation at all. > I agree. > > As others have argued, a signal is not special, in the sense that any > function can do anything, including emitting signals, so annotating it > doesn’t seem critical, as we apparently are fine without in all other cases. > > We don’t need one rule to rule them all either. Many signals are named > fooChanged(), and can perfectly well stand on their own, without annotations. > Corner cases like "emit pressed();” can be annotated with Q_EMIT or a comment > to make it clearer what’s going on. This is also what tipped me over. We have stronger conventions nowadays with property based APIs and the Changed suffix for the corresponding signals. We'll be fine without "emit" :-) Simon ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Wed, 26 Feb 2020 at 14:44, Tor Arne Vestbø wrote: > > We’re neither enforcing the use of ‘emit’ currently. And I honestly find > > most of the alternatives to be worse than no annotation at all. > > I agree. > > As others have argued, a signal is not special, in the sense that any > function can do anything, including emitting signals, so annotating it > doesn’t seem critical, as we apparently are fine without in all other cases. Yep, this part of it destroys the "annotate the yield operations" for me; if I call another function that then signals, I don't see the annotation, so the warm and fuzzy feeling of safety requires a very particular programming style. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
>>Were neither enforcing the use of emit currently. And I honestly >> find most of the alternatives to be worse than no annotation at all. As an illustration, for many years, I have the naming convention to start all my signals with... "signal" eg. signalChange(); This notation is so intuitive that I often forget to write "emit" before the call. Philippe On Wed, 26 Feb 2020 12:30:09 + Lars Knoll wrote: > > > > On 26 Feb 2020, at 10:38, Alex Blasche wrote: > > > > > > > >> -Original Message- > >> From: Lars Knoll > Im not trying to make this only about emit. But its the concrete > problem were facing now, and emit is IMO the one keyword where we > simply dont need a replacement because it has no real semantic meaning > in > >> C++. > >>> > >>> I don't think semantics matter here. It is all about annotation and > >>> readability. > >> With the same arguments we design APIs. While Kai's survey is inconclusive > >> about the actual solution, it is conclusive in one aspect. There is a > >> clear majority > >> to have sth in place for annotation/readability purposes. > >> > >> As Kai said, in this case a comment would do the trick just as well, no > >> need for a > >> keyword or macro: > >> > >> /*emit*/ mySignal(); or > >> mySignal(); // emit > > > > Can you see us adopting a coding style that enforces the use of such > > comments? Otherwise this will quickly change to comments being forgotten > > which makes the above suggestion less valuable. Although the alternatives > > have no semantics either they impress a stronger coding style than comments > > IMO. > > Were neither enforcing the use of emit currently. And I honestly find most > of the alternatives to be worse than no annotation at all. > > Cheers, > Lars > > > > > -- > > Alex > > ___ > Development mailing list > 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
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> On 26 Feb 2020, at 13:30, Lars Knoll wrote: > > > >> On 26 Feb 2020, at 10:38, Alex Blasche wrote: >> >> >> >>> -Original Message- >>> From: Lars Knoll > I’m not trying to make this only about emit. But it’s the concrete > problem we’re facing now, and emit is IMO the one keyword where we > simply don’t need a replacement because it has no real semantic meaning in >>> C++. I don't think semantics matter here. It is all about annotation and readability. >>> With the same arguments we design APIs. While Kai's survey is inconclusive >>> about the actual solution, it is conclusive in one aspect. There is a clear >>> majority >>> to have sth in place for annotation/readability purposes. >>> >>> As Kai said, in this case a comment would do the trick just as well, no >>> need for a >>> keyword or macro: >>> >>> /*emit*/ mySignal(); or >>> mySignal(); // emit >> >> Can you see us adopting a coding style that enforces the use of such >> comments? Otherwise this will quickly change to comments being forgotten >> which makes the above suggestion less valuable. Although the alternatives >> have no semantics either they impress a stronger coding style than comments >> IMO. > > We’re neither enforcing the use of ‘emit’ currently. And I honestly find most > of the alternatives to be worse than no annotation at all. I agree. As others have argued, a signal is not special, in the sense that any function can do anything, including emitting signals, so annotating it doesn’t seem critical, as we apparently are fine without in all other cases. We don’t need one rule to rule them all either. Many signals are named fooChanged(), and can perfectly well stand on their own, without annotations. Corner cases like "emit pressed();” can be annotated with Q_EMIT or a comment to make it clearer what’s going on. Tor Arne ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> On 26 Feb 2020, at 10:38, Alex Blasche wrote: > > > >> -Original Message- >> From: Lars Knoll I’m not trying to make this only about emit. But it’s the concrete problem we’re facing now, and emit is IMO the one keyword where we simply don’t need a replacement because it has no real semantic meaning in >> C++. >>> >>> I don't think semantics matter here. It is all about annotation and >>> readability. >> With the same arguments we design APIs. While Kai's survey is inconclusive >> about the actual solution, it is conclusive in one aspect. There is a clear >> majority >> to have sth in place for annotation/readability purposes. >> >> As Kai said, in this case a comment would do the trick just as well, no need >> for a >> keyword or macro: >> >> /*emit*/ mySignal(); or >> mySignal(); // emit > > Can you see us adopting a coding style that enforces the use of such > comments? Otherwise this will quickly change to comments being forgotten > which makes the above suggestion less valuable. Although the alternatives > have no semantics either they impress a stronger coding style than comments > IMO. We’re neither enforcing the use of ‘emit’ currently. And I honestly find most of the alternatives to be worse than no annotation at all. Cheers, Lars > > -- > Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> -Original Message- > From: Lars Knoll > >> I’m not trying to make this only about emit. But it’s the concrete > >> problem we’re facing now, and emit is IMO the one keyword where we > >> simply don’t need a replacement because it has no real semantic meaning in > C++. > > > > I don't think semantics matter here. It is all about annotation and > > readability. > With the same arguments we design APIs. While Kai's survey is inconclusive > about the actual solution, it is conclusive in one aspect. There is a clear > majority > to have sth in place for annotation/readability purposes. > > As Kai said, in this case a comment would do the trick just as well, no need > for a > keyword or macro: > > /*emit*/ mySignal(); or > mySignal(); // emit Can you see us adopting a coding style that enforces the use of such comments? Otherwise this will quickly change to comments being forgotten which makes the above suggestion less valuable. Although the alternatives have no semantics either they impress a stronger coding style than comments IMO. -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> I don't think semantics matter here. It is all about annotation and readability. With the same arguments we design APIs. While Kai's survey is inconclusive about the actual solution, it is conclusive in one aspect. There is a clear majority to have sth in place for annotation/readability purposes. You should I think take into account that the whole C++ community manages to do just fine without annotating calls to std::function (or $any_other_signal_slot_library_in_the_universe) in the same way - even though all of the "dangers" can still apply. On Wed, Feb 26, 2020 at 9:18 AM Alex Blasche wrote: > > > > -Original Message- > > From: Development On Behalf Of Lars > > Knoll > > > > I’m not trying to make this only about emit. But it’s the concrete > problem we’re > > facing now, and emit is IMO the one keyword where we simply don’t need a > > replacement because it has no real semantic meaning in C++. > > I don't think semantics matter here. It is all about annotation and > readability. With the same arguments we design APIs. While Kai's survey is > inconclusive about the actual solution, it is conclusive in one aspect. > There is a clear majority to have sth in place for annotation/readability > purposes. > > > > Qt relies on macros a lot, and while I have not followed the latest > Modules > > development, I'm sure macros pose a problem for a modularized Qt, too > > > > > > So while emit is the latest in the line of macro clashes, it's not the > first and it > > likely won't be the last. So, please, just removing 'emit' because it's > easy doesn't > > solve the problem for `signals` and `slots`. > > > > > > Can access specifiers have attributes? > > > public [[qt::slots]]: > > > > > > > Why do we need it, if functions can already have attributes? > > Because it is in the wrong spot. I want to spot the signal call in a cpp > file and not a header. I must assume that the reason why we had emit in the > first place (besides "slots" and "signals") is the same. > > > public: > > [[qt::slot]] void mySlot(); > > > > protected: > > [[qt::signal] void mySignal(); > > I’d love to have this too (in addition to [[qt::emit]]) > > -- > Alex > > ___ > Development mailing list > 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
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> On 26 Feb 2020, at 09:16, Alex Blasche wrote: > > > >> -Original Message- >> From: Development On Behalf Of Lars >> Knoll > > >> I’m not trying to make this only about emit. But it’s the concrete problem >> we’re >> facing now, and emit is IMO the one keyword where we simply don’t need a >> replacement because it has no real semantic meaning in C++. > > I don't think semantics matter here. It is all about annotation and > readability. With the same arguments we design APIs. While Kai's survey is > inconclusive about the actual solution, it is conclusive in one aspect. There > is a clear majority to have sth in place for annotation/readability purposes. As Kai said, in this case a comment would do the trick just as well, no need for a keyword or macro: /*emit*/ mySignal(); or mySignal(); // emit Both of those are IMO more readable than most of the other proposals we had. > >>> Qt relies on macros a lot, and while I have not followed the latest Modules >> development, I'm sure macros pose a problem for a modularized Qt, too >>> >>> So while emit is the latest in the line of macro clashes, it's not the >>> first and it >> likely won't be the last. So, please, just removing 'emit' because it's easy >> doesn't >> solve the problem for `signals` and `slots`. >>> >>> Can access specifiers have attributes? >>> public [[qt::slots]]: >>> >> >> Why do we need it, if functions can already have attributes? > > Because it is in the wrong spot. I want to spot the signal call in a cpp file > and not a header. I must assume that the reason why we had emit in the first > place (besides "slots" and "signals") is the same. Marc was asking about the declarations in the headers where we have signals/Q_SIGNALS and slots/Q_SLOTS. Those could be replaced by adding an attribute to the method declaration. Cheers, Lars > >> public: >> [[qt::slot]] void mySlot(); >> >> protected: >> [[qt::signal] void mySignal(); > > I’d love to have this too (in addition to [[qt::emit]]) > > -- > Alex > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> -Original Message- > From: Development On Behalf Of Lars > Knoll > I’m not trying to make this only about emit. But it’s the concrete problem > we’re > facing now, and emit is IMO the one keyword where we simply don’t need a > replacement because it has no real semantic meaning in C++. I don't think semantics matter here. It is all about annotation and readability. With the same arguments we design APIs. While Kai's survey is inconclusive about the actual solution, it is conclusive in one aspect. There is a clear majority to have sth in place for annotation/readability purposes. > > Qt relies on macros a lot, and while I have not followed the latest Modules > development, I'm sure macros pose a problem for a modularized Qt, too > > > > So while emit is the latest in the line of macro clashes, it's not the > > first and it > likely won't be the last. So, please, just removing 'emit' because it's easy > doesn't > solve the problem for `signals` and `slots`. > > > > Can access specifiers have attributes? > > public [[qt::slots]]: > > > > Why do we need it, if functions can already have attributes? Because it is in the wrong spot. I want to spot the signal call in a cpp file and not a header. I must assume that the reason why we had emit in the first place (besides "slots" and "signals") is the same. > public: > [[qt::slot]] void mySlot(); > > protected: > [[qt::signal] void mySignal(); I’d love to have this too (in addition to [[qt::emit]]) -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Hi, There are now 73 results to the survey, current results are at https://bugreports.qt.io/secure/attachment/92413/survey_result.pdf I tried to aggregate also the other suggestions, and ordering by absolute votes: mySignal() - 21 votes Q_EMIT mySignal() - 13 votes [[qt::emit]] mySignal() - 12 votes qemit mySignal() - 5 votes emit mySignal() - 3 votes qEmit(mySignal) - 1 vote keep the \"ugly\" q_emit but don\`t require it. - 1 vote method call with naming convention - 1 vote mySignal() // emit, let a comment look lik a comment - 1 vote [[emit]] - 1 vote emitmysignal() - 1 vote Thanks for participating! Kai > -Original Message- > From: Development On Behalf Of Kai > Köhne > Sent: Monday, February 24, 2020 4:31 PM > To: Ville Voutilainen ; Lars Knoll > > Cc: Thiago Macieira ; Qt development mailing > list > Subject: Re: [Development] A modest proposal: disable lower-case keywords > (emit, foreach, forever, signals, slots) by default > > Hi, > > Since this is arguably as much about taste as it is about technicalities, I > thought it might be interesting to do a quick poll in the form of a survey: > > https://www.1ka.si/a/255723 > > Disclaimer: Qt Project is not a democracy, so let's not pretend that whatever > gets most clicks gets implemented in the end. Still, I'm curious ... > > Kai > > > -Original Message- > > From: Development On Behalf Of > > Ville Voutilainen > > Sent: Monday, February 24, 2020 2:53 PM > > To: Lars Knoll > > Cc: Thiago Macieira ; Qt development > > mailing list > > Subject: Re: [Development] A modest proposal: disable lower-case > > keywords (emit, foreach, forever, signals, slots) by default > > > > On Mon, 24 Feb 2020 at 14:42, Lars Knoll wrote: > > > 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. > > > > Was the keyword ever required? Seems like it's just a taste difference > > from a > > > > qEmit(my_signal()); > > > > to write > > > > emit my_signal(); > > > > The first one can be namespaced, and thus its name lookup controlled. > > It also never clashes with a member name. > > Its worse aesthetics aside, if we'd had that since the beginning, we > > wouldn't be talking about the current clashes with std::osyncstream. > > ___ > > Development mailing list > > 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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> On 24 Feb 2020, at 23:29, Marc Mutz wrote: > > Hi Lars, others, > > On 2020-02-24 12:25, Lars Knoll wrote: >>> On 21 Feb 2020, at 17:39, Thiago Macieira 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. It’s also >> safer, as the keyword can be forgotten or applied to the wrong places. > > Please don't make this only about emit. We had clashes with signals in > boost.signals, we have suffered clashes with Window's min/max and several X11 > #defines, we know we should not inflict (non-all-uppercase) macros on the > world. I’m not trying to make this only about emit. But it’s the concrete problem we’re facing now, and emit is IMO the one keyword where we simply don’t need a replacement because it has no real semantic meaning in C++. > > Qt relies on macros a lot, and while I have not followed the latest Modules > development, I'm sure macros pose a problem for a modularized Qt, too. > > So while emit is the latest in the line of macro clashes, it's not the first > and it likely won't be the last. So, please, just removing 'emit' because > it's easy doesn't solve the problem for `signals` and `slots`. > > Can access specifiers have attributes? > public [[qt::slots]]: > Why do we need it, if functions can already have attributes? public: [[qt::slot]] void mySlot(); protected: [[qt::signal] void mySignal(); Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> On 25 Feb 2020, at 20:17, Matthew Woehlke wrote: > > On 21/02/2020 09.02, Ville Voutilainen wrote: >> 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. > > AFAIK, signals *can't* return, period. The signal body is written by > moc, not the developer, and I'm not aware of any way to generate a > signal method body that involves returning something. We’re on a tangent here, but signals and slots can have return values, and these are passed correctly through the generated signal emission code. It’s not recommended as it violates some of the principles signals/slots have been designed for, but there are some valid use cases. The way it works is that in case more than one slot is connected to such a signal, the return value of the last slot connected is returned, if nothing is connected a default constructed value is returned. > >> 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(); > > Personally, I would vote for: > > template > QObject::emit(Signal, Args&&...) > > ...which not only avoids an extra set of parentheses, but could actually > *verify* that what you're trying to emit is really a signal. (It has to > be a member function, because it needs `this`.) Sure we could do that, but it (as some of the other proposals) leads to a rather ugly syntax without solving any real problem. Signals/slots are a success because they are easy to use and just a simple function call on the emitting side. Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Tue, 25 Feb 2020 at 10:19, Ville Voutilainen
wrote:
> Or perhaps qEmit(this)->my_signal(Args...);
>
> and hide the befriending of qEmit (so that private/protected don't
This doesn't even need friending.
#include
template
struct qEmit
{
T* that;
qEmit(T* it) : that(it) {}
T* operator->() {return that;}
};
struct X
{
void sig1() {std::cout << "sig1\n";}
void sig2() {std::cout << "sig2\n";}
void foo() {
qEmit(this)->sig1();
qEmit(this)->sig2();
}
};
int main()
{
X x;
x.foo();
}
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Tue, 25 Feb 2020 at 22:17, Matthew Woehlke wrote: > Right, and when I realized that, it got me wondering, how many people > will need to call that specific function that are *also* using Qt *and* > will be unwilling to use Q_NO_KEYWORDS to work around the issue? You're getting back to the reason why renaming osyncstream::emit() was unconvincing, here. ;) But the reason why we are talking about this is to search for a solution where such clashes don't happen in the future. Yes, we know how to deal with boost::signals, yes, we know how to deal with X11 Status clashing with QSettings::Status, but maybe we shouldn't have to deal with these clashes that are our own doing because it's us defining the problematic macros. (In the X11 case, it's X11, not us.) We could be better-behaving citizens of the ecosystem, instead of saying "well we've been bad citizens for a long time, please just accommodate us, here's hacks that allow you to circumvent the problems we cause". ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 25/02/2020 14.58, Ville Voutilainen wrote: > On Tue, 25 Feb 2020 at 21:37, Matthew Woehlke wrote: >> - Until now, `emit` has rarely been used in code that needs to mix with Qt. >> >> - C++20 will have modules. >> >> - Modules are theoretically immune to the above issue. > > Module definitions are immune to macros affecting what they export, > but client code is not > immune to mixtures of module imports and header includes when the > latter defines a macro. > If you import a Std.IOStream module and then include QObject, you > can't call std::osyncstream::emit(). Right, and when I realized that, it got me wondering, how many people will need to call that specific function that are *also* using Qt *and* will be unwilling to use Q_NO_KEYWORDS to work around the issue? It's not as dire as not being able to use that module *at all*, directly *or indirectly*¹, in code that also uses Qt. More likely, it will be boost::signals again, which doesn't seem to have been a catastrophe. (¹ ...if your other third-party dependencies modularize, or don't use that method in headers.) -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Tue, 25 Feb 2020 at 21:37, Matthew Woehlke wrote: > > On 24/02/2020 07.34, Edward Welbourne wrote: > > Mitch Curtis (24 February 2020 13:22) > >> I don't think anyone has explained what that harm is yet. > > > > #define emit > > > > causes problems when you import a header that declares > > > > void emit(Type arg); > > > > and the compiler sees > > > > void (Type arg); > > > > and throws a wobbly. > > - Until now, `emit` has rarely been used in code that needs to mix with Qt. > > - C++20 will have modules. > > - Modules are theoretically immune to the above issue. Module definitions are immune to macros affecting what they export, but client code is not immune to mixtures of module imports and header includes when the latter defines a macro. If you import a Std.IOStream module and then include QObject, you can't call std::osyncstream::emit(). > Where, exactly, is the problem? It seems to me we are making a big deal > out of something that will *still* only be a problem when mixing Qt > (with no QT_NO_KEYWORDS) and *certain uses* of . Correct. > This doesn't seem appreciably different from the existing situation with > boost::signals. Ergo, I am confused why we are all acting like the sky > is falling? Indeed. > Maybe we should, at least, take a step back and wait to see if this > *actually affects many people* before worrying about it? Seems reasonable. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 24/02/2020 07.34, Edward Welbourne wrote: > Mitch Curtis (24 February 2020 13:22) >> I don't think anyone has explained what that harm is yet. > > #define emit > > causes problems when you import a header that declares > > void emit(Type arg); > > and the compiler sees > > void (Type arg); > > and throws a wobbly. - Until now, `emit` has rarely been used in code that needs to mix with Qt. - C++20 will have modules. - Modules are theoretically immune to the above issue. Where, exactly, is the problem? It seems to me we are making a big deal out of something that will *still* only be a problem when mixing Qt (with no QT_NO_KEYWORDS) and *certain uses* of . This doesn't seem appreciably different from the existing situation with boost::signals. Ergo, I am confused why we are all acting like the sky is falling? Maybe we should, at least, take a step back and wait to see if this *actually affects many people* before worrying about it? -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 21/02/2020 09.02, Ville Voutilainen wrote: > 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. AFAIK, signals *can't* return, period. The signal body is written by moc, not the developer, and I'm not aware of any way to generate a signal method body that involves returning something. > 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(); Personally, I would vote for: template QObject::emit(Signal, Args&&...) ...which not only avoids an extra set of parentheses, but could actually *verify* that what you're trying to emit is really a signal. (It has to be a member function, because it needs `this`.) -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> On 24. Feb 2020, at 13:48, Mitch Curtis wrote: > >> -Original Message- >> From: Lars Knoll >> Sent: Monday, 24 February 2020 1:40 PM >> To: Mitch Curtis >> Cc: Thiago Macieira ; Qt development mailing >> list >> 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 > <mailto:mitch.cur...@qt.io> > wrote: >> >> >> -Original Message- >> From: Development > <mailto:development-boun...@qt-project.org> > On Behalf Of >> Lars Knoll >> Sent: Monday, 24 February 2020 12:25 PM >> To: Thiago Macieira > <mailto:thiago.macie...@intel.com> > >> Cc: Qt development mailing list > 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 >> 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 thinki
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Tue, 25 Feb 2020 at 00:30, Marc Mutz via Development wrote: > Qt relies on macros a lot, and while I have not followed the latest > Modules development, I'm sure macros pose a problem for a modularized > Qt, too. Header units can still export macros. Macros don't go into header units or named modules from the client, but that doesn't save the situation - if you import osyncstream and #define emit (via whatever means), you still can't call osynctream::emit. So for modules, the clashes are not as likely, but they aren't completely unavoidable as long as emit is a macro. > Can access specifiers have attributes? > public [[qt::slots]]: > That is pretty much exactly how the 'metaclass' (really just reflection+injection, with the reflection+injection metaprograms called from the class definition body, because that's where Q_OBJECT resides) approach envisions doing slots; there was an idea floated around that you could write public: ... current [[qt::slots]]: ... current: so that 'current' is just 'public', or actually whatever was the access at that point. Then 'slots/Q_SLOTS' can expand into 'current [[qt::slots]]:' and the meta-transformation can generate the code moc would generate today. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Mon, 24 Feb 2020 at 17:17, Allan Sandfeld Jensen wrote: > Yeah you would need something like qEmit(_signal, Args..) or without & > using a macro. Or.. qEmit(std::bind(_signal, Args...)); Or perhaps qEmit(this)->my_signal(Args...); and hide the befriending of qEmit (so that private/protected don't thwart this) inside Q_OBJECT. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Il 24/02/20 13:48, Mitch Curtis ha scritto: 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. :) Not to mention: code review, which doesn't highlight anything at all. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Hi Lars, others, On 2020-02-24 12:25, Lars Knoll wrote: On 21 Feb 2020, at 17:39, Thiago Macieira 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. It’s also safer, as the keyword can be forgotten or applied to the wrong places. Please don't make this only about emit. We had clashes with signals in boost.signals, we have suffered clashes with Window's min/max and several X11 #defines, we know we should not inflict (non-all-uppercase) macros on the world. Qt relies on macros a lot, and while I have not followed the latest Modules development, I'm sure macros pose a problem for a modularized Qt, too. So while emit is the latest in the line of macro clashes, it's not the first and it likely won't be the last. So, please, just removing 'emit' because it's easy doesn't solve the problem for `signals` and `slots`. Can access specifiers have attributes? public [[qt::slots]]: Thanks, Marc ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
24.02.2020, 18:19, "Allan Sandfeld Jensen" : > > Yeah you would need something like qEmit(_signal, Args..) or without & > using a macro. Or.. qEmit(std::bind(_signal, Args...)); FWIW, using lambda expression is almost always a better solution that std::bind. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Hi, Since this is arguably as much about taste as it is about technicalities, I thought it might be interesting to do a quick poll in the form of a survey: https://www.1ka.si/a/255723 Disclaimer: Qt Project is not a democracy, so let's not pretend that whatever gets most clicks gets implemented in the end. Still, I'm curious ... Kai > -Original Message- > From: Development On Behalf Of > Ville Voutilainen > Sent: Monday, February 24, 2020 2:53 PM > To: Lars Knoll > Cc: Thiago Macieira ; Qt development mailing > list > Subject: Re: [Development] A modest proposal: disable lower-case keywords > (emit, foreach, forever, signals, slots) by default > > On Mon, 24 Feb 2020 at 14:42, Lars Knoll wrote: > > 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. > > Was the keyword ever required? Seems like it's just a taste difference from a > > qEmit(my_signal()); > > to write > > emit my_signal(); > > The first one can be namespaced, and thus its name lookup controlled. > It also never clashes with a member name. > Its worse aesthetics aside, if we'd had that since the beginning, we wouldn't > be > talking about the current clashes with std::osyncstream. > ___ > Development mailing list > 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
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Monday, 24 February 2020 15:03:41 CET Ville Voutilainen wrote: > On Mon, 24 Feb 2020 at 15:52, Ville Voutilainen > > wrote: > > On Mon, 24 Feb 2020 at 14:42, Lars Knoll wrote: > > > 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.> > > Was the keyword ever required? Seems like it's just a taste difference > > from a > > > > qEmit(my_signal()); > > > > to write > > > > emit my_signal(); > > > > The first one can be namespaced, and thus its name lookup controlled. > > It also never clashes with a member name. > > Its worse aesthetics aside, if we'd had that since the beginning, we > > wouldn't be talking about the current clashes > > with std::osyncstream. > > Hah, except it of course doesn't work with my_signal that returns void. Yeah you would need something like qEmit(_signal, Args..) or without & using a macro. Or.. qEmit(std::bind(_signal, Args...)); 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Mon, 24 Feb 2020 at 15:52, Ville Voutilainen wrote: > > On Mon, 24 Feb 2020 at 14:42, Lars Knoll wrote: > > 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. > > Was the keyword ever required? Seems like it's just a taste difference from a > > qEmit(my_signal()); > > to write > > emit my_signal(); > > The first one can be namespaced, and thus its name lookup controlled. > It also never clashes with a member name. > Its worse aesthetics aside, if we'd had that since the beginning, we > wouldn't be talking about the current clashes > with std::osyncstream. Hah, except it of course doesn't work with my_signal that returns void. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Mon, 24 Feb 2020 at 14:42, Lars Knoll wrote: > 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. Was the keyword ever required? Seems like it's just a taste difference from a qEmit(my_signal()); to write emit my_signal(); The first one can be namespaced, and thus its name lookup controlled. It also never clashes with a member name. Its worse aesthetics aside, if we'd had that since the beginning, we wouldn't be talking about the current clashes with std::osyncstream. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Mon, 24 Feb 2020 at 14:35, Mitch Curtis wrote: > > > > > 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. > > Personally I find it a bit concerning that you don't consider readability or > maintainability a plausible explanation for annotating code with emit. I find it rather more concerning that you make such a claim, when in the quoted bit I do consider readability and maintainability such plausible explanations. Perhaps that's because I don't consider vague claims of readability and maintainability plausible, but I do consider readability and maintainability with an actual reason plausible, and typically-calling-up-into-arbitrary-code-that-can-and-does-call-back-to-us is such a reason. >Though I can rest easy with the knowledge that you're not the sole authority >for what constitutes a plausible explanation, despite how you worded it. Well, for what constitutes a plausible explanation to me, I actually am the sole authority. > I can only assume that that same mindset must also encapsulate all of the > developers who never wrote any comments for their code because... it made > sense to them and that's all matters. Did you plan to set that strawman on fire, or are you just playing with it? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> -Original Message- > From: Edward Welbourne > Sent: Monday, 24 February 2020 1:35 PM > To: Mitch Curtis > Cc: Qt development mailing list ; Lars Knoll > ; Thiago Macieira > Subject: Re: [Development] A modest proposal: disable lower-case > keywords (emit, foreach, forever, signals, slots) by default > > Mitch Curtis (24 February 2020 13:22) > > I don't think anyone has explained what that harm is yet. > > #define emit > > causes problems when you import a header that declares > > void emit(Type arg); > > and the compiler sees > > void (Type arg); > > and throws a wobbly. > > Eddy. Sorry, I should have been more specific: I meant any form of emit (e.g. qEmit) that doesn't conflict. So far the arguments have been: - It's ugly. Purely subjective. Are code comments also ugly? - It can be misused I've never seen it happen. In the very few cases where it does, the consequences are so insignificant as to not even be worth considering. - It's redundant Only when the major/popular IDEs that a significant portion of Qt users use can highlight signal emissions. Until then, it's not redundant if it improves readability. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> -Original Message- > From: Lars Knoll > Sent: Monday, 24 February 2020 1:40 PM > To: Mitch Curtis > Cc: Thiago Macieira ; Qt development mailing > list > 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 <mailto:mitch.cur...@qt.io> > wrote: > > > -Original Message- > From: Development <mailto:development-boun...@qt-project.org> > On Behalf Of > Lars Knoll > Sent: Monday, 24 February 2020 12:25 PM > To: Thiago Macieira <mailto:thiago.macie...@intel.com> > > Cc: Qt development mailing list 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 > 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
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 mailto:mitch.cur...@qt.io>> wrote: -Original Message- From: Development mailto:development-boun...@qt-project.org>> On Behalf Of Lars Knoll Sent: Monday, 24 February 2020 12:25 PM To: Thiago Macieira mailto:thiago.macie...@intel.com>> Cc: Qt development mailing list 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 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. 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. 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
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> -Original Message- > From: Development On Behalf Of > Ville Voutilainen > Sent: Friday, 21 February 2020 3:02 PM > To: Christian Kandeler > Cc: development@qt-project.org > Subject: Re: [Development] A modest proposal: disable lower-case > keywords (emit, foreach, forever, signals, slots) by default > > On Fri, 21 Feb 2020 at 15:44, Christian Kandeler > wrote: > > > > On Fri, 21 Feb 2020 15:00:53 +0200 > > Ville Voutilainen wrote: > > > > > On Fri, 21 Feb 2020 at 14:58, Sérgio Martins > 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. Personally I find it a bit concerning that you don't consider readability or maintainability a plausible explanation for annotating code with emit. Though I can rest easy with the knowledge that you're not the sole authority for what constitutes a plausible explanation, despite how you worded it. I can only assume that that same mindset must also encapsulate all of the developers who never wrote any comments for their code because... it made sense to them and that's all matters. > 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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Mitch Curtis (24 February 2020 13:22) > I don't think anyone has explained what that harm is yet. #define emit causes problems when you import a header that declares void emit(Type arg); and the compiler sees void (Type arg); and throws a wobbly. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> -Original Message- > From: Development On Behalf Of > Lars Knoll > Sent: Monday, 24 February 2020 12:25 PM > To: Thiago Macieira > Cc: Qt development mailing list > 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 > 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 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). > Cheers, > Lars > > ___ > Development mailing list > 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
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 24 Feb 2020, at 12:30, André Somers mailto:an...@familiesomers.nl>> wrote: Hi Lars, Sent from my phone, please excuse my brevity On 24 Feb 2020, at 12:27, Lars Knoll mailto:lars.kn...@qt.io>> wrote: On 21 Feb 2020, at 17:39, Thiago Macieira 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. It’s also safer, as the keyword can be forgotten or applied to the wrong places. You seem to assume everyone used QtCreator as their IDE of choice. That is not a reasonable assumption I think. No, but ‘emit’ as a macro that expands to nothing (and for that matter all other proposals such as [[qt::emit]] or qEmit()) is not a great solution neither. It can easily be forgotten or placed in the wrong position (and I’ve seen both quite a few times). Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Hi Lars, Sent from my phone, please excuse my brevity > On 24 Feb 2020, at 12:27, Lars Knoll wrote: > > >> >> On 21 Feb 2020, at 17:39, Thiago Macieira 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. It’s also safer, as the keyword can be forgotten or > applied to the wrong places. You seem to assume everyone used QtCreator as their IDE of choice. That is not a reasonable assumption I think. André > > Cheers, > Lars > > ___ > Development mailing list > 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
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 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. It’s also safer, as the keyword can be forgotten or applied to the wrong places. Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> On 24 Feb 2020, at 10:54, Ville Voutilainen > wrote: > > On Mon, 24 Feb 2020 at 11:23, Jean-Michaël Celerier > wrote: >> >> A good inspiration for that feature would be the Just My Code feature of >> recent visual studio : >> https://docs.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2019 > > That is indeed what I'm gunning for. :) If our problem is that users > mistakenly step into moc-generated > code, let's fix that in our tooling instead of inventing new language > keywords. Users might want to skip all Qt code. Qt developers mainly want to skip all moc-generated code I suppose. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Mon, 24 Feb 2020 at 11:23, Jean-Michaël Celerier wrote: > > A good inspiration for that feature would be the Just My Code feature of > recent visual studio : > https://docs.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2019 That is indeed what I'm gunning for. :) If our problem is that users mistakenly step into moc-generated code, let's fix that in our tooling instead of inventing new language keywords. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
A good inspiration for that feature would be the Just My Code feature of recent visual studio : https://docs.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2019 Best, Jean-Michaël On Mon, Feb 24, 2020 at 8:51 AM Shawn Rutledge wrote: > > > On 22 Feb 2020, at 12:57, Ville Voutilainen > wrote: > > > > On Sat, 22 Feb 2020 at 13:07, André Pönitz wrote: > >>> Buy a debugger that can skip code that you didn't write. > >> > >> The point was that in a such a situation I, as user, would not even > >> try to step in when the call is marked with 'emit'. This 'emit' in > >> a line *is* valuable markup, that saves me time. > >> > >> That's unrelated to what the debugger would or could do if I did step > in, > >> I just don't need to follow that path. > >> > >> [And apart from that: There's no need to *buy* such debugger, e.g. gdb's > >> 'skip' actually works] > > > > It occurs to me that, in case Creator doesn't do that already, we could > make its > > debugger UI to automatically tell the underlying debugger to skip > > moc-generated code, > > as a default. > > I’m probably dreaming, but wouldn’t it be cool if it were possible somehow > to “step into” each handler function that is connected, while skipping over > the details of how we get there…. At least for direct connections. > > ___ > Development mailing list > 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
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 2020-02-21 17:31, Thiago Macieira wrote: On Friday, 21 February 2020 03:21:32 PST Ville Voutilainen wrote: Yes, and the name change was discussed but rejected. Do you know why it was such strong against? Was it, "darn it's too late" or was it "we don't care"? Both. I think the argument that Qt uses 'emit' as a macro would have caught with people at design time. Not so on the last day of the last meeting before C++20 was to go DIS. That said, it might have even caught had it only been `bool basic_syncstream::emit()`, because try_emit() was actually deemed better by some influential people, due to the bool return type. But the cause was lost when `void basic_osyncstream::emit()` entered the game, and so we couldn't keep the stem, we'd have to bikeshed a new verb altogether. Thanks, Marc ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> On 22 Feb 2020, at 12:57, Ville Voutilainen > wrote: > > On Sat, 22 Feb 2020 at 13:07, André Pönitz wrote: >>> Buy a debugger that can skip code that you didn't write. >> >> The point was that in a such a situation I, as user, would not even >> try to step in when the call is marked with 'emit'. This 'emit' in >> a line *is* valuable markup, that saves me time. >> >> That's unrelated to what the debugger would or could do if I did step in, >> I just don't need to follow that path. >> >> [And apart from that: There's no need to *buy* such debugger, e.g. gdb's >> 'skip' actually works] > > It occurs to me that, in case Creator doesn't do that already, we could make > its > debugger UI to automatically tell the underlying debugger to skip > moc-generated code, > as a default. I’m probably dreaming, but wouldn’t it be cool if it were possible somehow to “step into” each handler function that is connected, while skipping over the details of how we get there…. At least for direct connections. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Sat, 22 Feb 2020 at 13:07, André Pönitz wrote: > > Buy a debugger that can skip code that you didn't write. > > The point was that in a such a situation I, as user, would not even > try to step in when the call is marked with 'emit'. This 'emit' in > a line *is* valuable markup, that saves me time. > > That's unrelated to what the debugger would or could do if I did step in, > I just don't need to follow that path. > > [And apart from that: There's no need to *buy* such debugger, e.g. gdb's > 'skip' actually works] It occurs to me that, in case Creator doesn't do that already, we could make its debugger UI to automatically tell the underlying debugger to skip moc-generated code, as a default. > > 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 > > Is that documented, perhaps with a bit more detail, somewhere? Not that I know of - the LWG issue hasn't been updated yet. Is there some particular detail that you're missing? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Fri, Feb 21, 2020 at 11:03:19PM +0200, Ville Voutilainen wrote: > On Fri, 21 Feb 2020 at 22:11, André Pönitz 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. The point was that in a such a situation I, as user, would not even try to step in when the call is marked with 'emit'. This 'emit' in a line *is* valuable markup, that saves me time. That's unrelated to what the debugger would or could do if I did step in, I just don't need to follow that path. [And apart from that: There's no need to *buy* such debugger, e.g. gdb's 'skip' actually works] > > 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. I stated as pre-condition that this is about "code that follows the convention of using signals only for inside-out communication". > > 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 Is that documented, perhaps with a bit more detail, somewhere? Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
