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 responsib
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] Can QImage format plugins require QGuiApplication?
On 4/14/20 11:30 AM, Allan Sandfeld Jensen wrote: > No, any GUI-related API requires QGuiApplication, and any widget-related > API QApplication. > In theory, but see https://codereview.qt-project.org/c/qt/qtbase/+/47846 I would stick to the documented contract, without any fancy ad-hoc workarounds that work today and may get broken tomorrow. Case in point, image plugins have the right of happily start loading fonts, accessing the clipboard, querying the screen DPI and whatnot. Any breakage caused by this because of a lack of a QGuiApplication instance is a bug in application code, not Qt. 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: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Can QImage format plugins require QGuiApplication?
On Dienstag, 14. April 2020 02:08:22 CEST Giuseppe D'Angelo via Development wrote: > Hi, > > On 4/14/20 1:34 AM, Konstantin Tokarev wrote: > >> The golden rule is that you're not allowed to touch any Qt API without > >> creating a Q*Application object first, unless the documentation says > >> otherwise. > > > > Question is whether Q_Core_Application should be sufficient for using and > > image format plugin, or QGuiApplication/QApplication is required. > > No, any GUI-related API requires QGuiApplication, and any widget-related > API QApplication. > In theory, but see https://codereview.qt-project.org/c/qt/qtbase/+/47846[1] Best regards Allan [1] https://codereview.qt-project.org/c/qt/qtbase/+/47846 ___ 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 be
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
