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)).