I appreciate this being brought up. Some sort of __UUID__ crossed my
mind while putting together this proposal. The
design of such a UUID is not at all clear to me as a traditional UUID
would introduce nondeterminism and ODR
issues, as mentioned by others, and something based on file and source
location would introduce a fair bit of
complexity.

It's unclear to me that __FILE__ is enough to help with ODR issues and
providing truly unique identifiers. Canonical
paths break down for hardlinks. Some #pragma once implementations use
file contents to uniquely identify files, that
could be used here, however this is becoming increasingly complex.

I'm weary of feature-creeping this paper; my goal is to standardize
existing practices rather than introduce new
features. It might be worth considering this for a follow-on paper.
Even if some sort of __UUID__ were provided, it
would still be beneficial to standardize __COUNTER__ given its widespread use.

On Thu, Aug 22, 2024 at 9:07 AM René Ferdinand Rivera Morell via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Thu, Aug 22, 2024 at 10:29 AM Thiago Macieira <thiago_at_[hidden]> wrote:
> >
> > On Thursday 22 August 2024 08:22:36 GMT-7 René Ferdinand Rivera Morell via
> > Std-Proposals wrote:
> > > Given that.. It would be more useful to standardize some form of
> > > __UUID__ that matches the current __COUNTER__ use cases.
> >
> > Why would it be? Wouldn't it need to guarantee it doesn't return a duplicate?
> > In which case, the UUID implementation will probably be based on a counter.
>
> A UUID could hash and take into account context like line, source
> file, function, to create more stable keys that a counter can do.
>
>
> --
> -- René Ferdinand Rivera Morell
> -- Don't Assume Anything -- No Supone Nada
> -- Robot Dreams - http://robot-dreams.net
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals