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

[Ville Voutilainen]

On Wed, 21 Feb 2024 at 19:56, Thiago Macieira <thiago.macieira at intel.com> wrote:
>
> On Wednesday, 21 February 2024 09:19:19 PST Mathias Hasselmann via Development
> wrote:
> > How that?
> >
> > https://wiki.qt.io/Coding_Conventions#Things_to_avoid says:
> >
> > "Avoid the use of anonymous namespaces in favor of the static keyword if
> > possible."
>
> Back in the day, this was a better suggestion. Now, it's equivalent so it's
> distinction without a difference.

Not quite. I happened to be the evil NB representative who convinced
WG21 to take a serious look
at undoing the deprecation of static in namespace scope in favor of
using unnamed namespaces,
and this Core Issue elaborates why:
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#174

To what extent the second bullet is relevant any more, I don't know.
But for compatibility reasons, and not
just for legacy compatibility reasons, the distinction isn't without a
difference, because there is a difference
in some code not being able to use unnamed namespaces.

Now, having said that, that doesn't mean we couldn't recommend using
unnamed namespaces instead of
static in namespace scope, for our own new C++ code. We technically
could, but as Andre says, there are plausible reasons why
some programmers might just prefer using simple statics instead of
wrapping in unnamed namespaces.

In general, I would prefer style guides and design guides and
programming guides to help programmers
avoid mistakes, and to write good code. Using static in a namespace
scope isn't a mistake, and it isn't
bad code. It's a simple facility that various programmers easily
understand, and use correctly.

Are unnamed namespaces strictly better than using static in namespace
scope? I don't think so.

Are unnamed namespaces strictly worse than using static in namespace
scope? I don't think so, either.

What I do think is that the trade-offs of either of them aren't
obviously applicable to every situation.
And as Andre points out, there are trade-offs that aren't just
differences in semantics.

It sure looks like we should certainly make *some* change in those
conventions, because the referred
standardese, which is now [basic.link]/4, certainly doesn't give names
declared in an unnamed namespace
external linkage.