`_` is a really good point, I forgot that has been accepted. This does
allow ODR issues to be resolved by simply preferring `_` for such
uses.

> If you don't want to reference the name then the only use case I can
think of is to leverage its construction and destruction side effects.

This is what google benchmark uses it for
https://godbolt.org/z/fh5f1qY3G. Standardizing
__attribute__((constructor)) would probably be more controversial, and
it wouldn't solve this use case unless paired with an anonymous
namespace.

Some of the benefit of standardizing __COUNTER__ is that it's an
opportunity to make existing widespread use more well-formed. I'm sure
there are plenty of inadvertent ODR violations today as a result of
__COUNTER__. Would changing ODR from requiring the same token sequence
to requiring the same observable behavior be too radical?
Alternatively, maybe identifiers could be allowed to differ?

Jeremy

On Sat, Aug 24, 2024 at 8:24 AM Andrey Semashev via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On 8/24/24 14:18, Marcin Jaczewski via Std-Proposals wrote:
> >
> > I now consider if a file should be even used in this?
> > It could be possible to deduce based on the statement how to generate
> > an identifier.
> > Let consider this case:
> >
> > ```
> > //file a.h
> > int __unique_name__;
> >
> > //file b.cpp
> > namespace Foo
> > {
> > #include "a.h"
> > }
> >
> > //file c.cpp
> > namespace Bar
> > {
> > #include "a.h"
> > }
> > ```
> >
> > Should these values have the same name?
> > For me even if this identifier is from the same file it should be independent.
> >
> > As far I see this should work more based on immediate context than
> > preprocessor state
> > (like what was include chain).
> >
> > For example, I have:
> >
> > ```
> > inline int __unique_name__ = 5;
> > ```
> >
> > Is it safe to assume that in any TU that encounters this definition in
> > the global namespace
> > it could assume this is the same object?
>
> What is the use case for __unique_name__ at namespace scope? Assuming
> that it always expands to a unique name, there would be no way to
> reference that variable.
>
> If you do want to reference the variable but want to have a unique
> variable in every TU that has it then you can already achieve that with
> anonymous namespaces and `static`.
>
> If you don't want to reference the name then the only use case I can
> think of is to leverage its construction and destruction side effects.
> In which case, a better solution would be to get rid of the object in
> the first place and standardize gcc's __attribute__((constructor)) and
> __attribute__((destructor)).
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals