[Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?

[Ville Voutilainen]

On Wed, 21 Feb 2024 at 21:38, apoenitz <apoenitz at t-online.de> wrote:

> >    Use unnamed namespaces for all internal/non-exported entities. Functions can
> >    alternatively be marked `static` in the global namespace. Marking functions
> >    `static` also in the unnamed namespace can help readability, particularly in reviews.
>
> That's technically an option, but again not a good one in my book. There is no
> advantage /known to me/ /for functions/ to be in the anonymous namespace instead
> of being 'static', and I listed a few cases where there are disadvantages.
>
> This change also does not solve the "problem" of having /different/ rules than
> the (self-proclaimed...) "Core Guidelines" which was - to me - the main reason
> for the proposed change.

Well.. ..a recognized problem with the Core Guidelines is that not all
of the guidelines in it
come with the strongest of rationale, some of them are highly
stylistic, and biased towards
certain author preferences that don't exactly withstand hard scrutiny.
The cost of symbols
in intermediate build artifacts is one of the things that a particular
origin of some of these guidelines,
namely portions of "C++ Coding Standards: 101 Rules, Guidelines, and
Best Practices"
was somewhat ill-equipped to consider in sufficient detail.

So, I highly recommend taking the Core Guidelines with quite a pinch
of salt, in fact a bucket,
not a pinch. They haven't been field-tested in serious anger. They
might look like good ideas,
but they might not work where the real rubber hits the road.

My favorite example is
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-dynamic_cast
It basically bans static_cast downcasts in a class hierarchy, so
despite quickly mentioning "using CRTP
carefully", it makes very strong insinuations of CRTP being banned.
The problem is You Can't Do That,
you can't use a dynamic_cast in a whole lot of class hierarchies
because they aren't polymorphic,
and the rule is very unclear about what using CRTP "carefully" means.

The C++23 "deduced this" fixes the problem, removes the need to do
such static downcasts,
and removes the need for C, R, and P in CRTP. :)
Nevertheless, that's a golden example of a Core Guidelines rule that
you, after considering adopting
it everywhere in your code, must deem nonsense, despite all the lofty
hopes of the authors of
these rules being infallible expert programmers who know exactly what
it's like to face real-life
engineering problems day in day out. I trust you can figure from all
those colorful words whether
I really think those authors are exactly that, or perhaps sometimes less so. :)