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

[apoenitz]

On Wed, Feb 21, 2024 at 06:56:41PM +0000, Jøger Hansegård via Development wrote:
> >>    Our Qt coding conventions ([1]https://wiki.qt.io/Coding_Conventions)
> >>    has a statement on the use of unnamed (anonymous) namespaces. As far as
> >>    I understand, this statement is now outdated.
> 
> > [I'll assume we are talking about functions here.]
> 
> Anonymous namespaces can be quite helpful to avoid name clashes of non-function types.

Non-function types are practically not covered by the current rule, as it has
an 'static [...] if possible' and there's no possibility to have 'static' on enums
and types, and it has a different meaning for e.g. class members.

> Quite often I see both local functions and other local entities in the same cpp
> file. I don't want to recommend against moving local functions into the unnamed
> namespace unless there is a technical reason why we shouldn't.

I gave some numbers in the previous mail that I considered at the time of its
writing a technical reason.

What would be an acceptable 'technical reason' here?
 
> > It would be a change to the worse in my book which I personally would not like.
> > Anonymous namespaces are harder to set up and to maintain and produce at best
> > identical results compared to static'
> 
> Would an option be to change from:
> 
>    Avoid the use of anonymous namespaces in favor of the static keyword
>    if possible. A name localized to the compilation unit with static is
>    guaranteed to have internal linkage. For names declared in anonymous
>    namespaces the C++ standard unfortunately mandates external linkage.
>    (7.1.1/6, or see various discussions about this on the gcc mailing
>    lists)
> 
> to
> 
>    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.

Andre'