On 14 Apr 2020, at 10:17, Nathan Myers <n...@cantrip.org<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 <n...@cantrip.org<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 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. And except for the case of those three legacy macros (signals/slots/emit), I do believe Qt has been extremely careful to keep its headers clean. Cheers, Lars
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development