On Wed, Nov 02, 2022 at 02:25:25PM +0000, Marc Mutz via Development wrote:
> Hi Volker,
>
> On 14.10.22 17:12, Volker Hilsheimer via Development wrote:
> > Anyway, I’ve added the respective text to the coding convention wiki
> > page.
> > https://wiki.qt.io/Coding_Conventions
>
> Having read the thread in total, I'm surprised about this outcome.
> AFAIK, we haven't had problems with traditional include guards,
[Funnily enough, the same could be said for a significant part (read:
pretty much all) the deprecations and API-removals since ~5.12]
> yet, and no compelling use-case for #pragma once was presented, so I
> don't see why we're now allowing it.
The "user case" is that in Real Life(TM)
(a) keeping the names of include guards sensible and consistent and
"legal" is a pain. Talking about "identifiers reserved for use
by C++ implementation" (double underscores, underscore plus
uppercase - and don't think about what "uppercase" /actually/ means)
is something that quite a few people don't want to do every second week.
(b) it gives the concept a name. It is /one/ /short/ line that hardly can
be misspelled, bears a meaning, and typically doesn't need discussion
besides silencing the "Fire! Wolves! Non-Standard!" voices.
Compare that to the three lines, that could be wrong, could mean
something else, could use arbritrary names for the guards, which by
itself are a perfect ground for bikeshedding and busy-work
to "fix" them [1].
> Esp. since the rule as written is more
> complicated than "always use header guards".
[Oh.... "complicated"?
Once we had QString and QByteArray (and the admittedly ill-conceived
QStringRef). Now we have QStringView, QAnyStringView, QByteArrayView,
... and when asking what the prefered getter/setter-signature for
"Qt-style" interfaces is the answer I get is "We'd guess $X, but the
only guy that knows for sure is on holiday". And that's for "developers
using Qt", not "developers _of_ Qt". Is that something you'd
call "complicated"?
Andre',
wondering whether he actually should read this list during vacations.
PS:
[1] https://en.wikipedia.org/wiki/Busy_work - just to make sure:
this bears a /negative/ connotated.
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
