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 t
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
[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
