On 4/13/20 3:41 PM, Ville Voutilainen wrote:
On Mon, 13 Apr 2020 at 06:11, Nathan Myers <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.
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
