On 4/14/20 5:28 AM, Lars Knoll wrote:
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:
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 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 were 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.
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.
Qt's failing was criticized immediately upon release.
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.
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.
Those users who want to continue using the macros will know
how to get them, and can then take personal responsibility
for their use. I feel confident they will not bother WG21
over any problems their choice causes them.
Nathan Myers
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
