(1) This conversation is largely pointless because it'll never happen (see
#3).
(2) Personally I'd see nothing wrong with a compiler such as Clang or GCC
adding the built-in macro `__UUID__` — similar to `__COUNTER__`, but giving
a UUID each time it's evaluated instead of a monotonically increasing
number.
(3) However, AFAIK, no compiler vendor has ever seen any pressure from
actual users to do so. If anyone really had a *desire* or a *real-world
use-case* for this, as opposed to hypothetical mailing-list bloviation,
they'd pursue a feature request with their vendor.
(4) If my vendor did provide `__UUID__`, and my source code did contain a
use of `__UUID__`, I'd darn well expect it to give me a universally unique
identifier on each evaluation. If it gave me an identifier that collided
with an identifier from another file — or an identifier from somewhere on
the Internet — or an identifier from this very same file compiled thirty
seconds ago — that would indicate its *utter* failure at its *single job*,
which, again, is to produce *universally unique* identifiers.
(5) Maybe some participants in this thread are more interested in
"preprocessor and/or library features for manipulating hex strings" or
"preprocessor and/or library features for hashing the token stream of the
current TU" or whatever. That's fine, but you should be aware that it's not
remotely the same thing as "producing universally unique identifiers." You
might even get a better reception for your actual ideas if you decoupled
them from the (perhaps ill-advised; see #3) idea of universal uniqueness.

–Arthur


On Mon, Mar 10, 2025 at 11:37 AM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:

> People want random numbers at compile time that stay the same if they
> hit "Rebuild" but which are still sufficiently random. Even though not
> every C++ implementation is guaranteed to have a 128-Bit integer type,
> I'm still going to go with 128-Bit random numbers, which I refer to
> loosely as a "UUID" because there is absolutely no merit in monkeying
> about with the so-called "different versions" of UUID. Nobody cares
> about the current time or your network card's MAC address. We just
> want a random number, so I use the term UUID to mean a 128-Bit random
> number.
>
> So there's two ways of doing this:
>
> (Method No. 1) A preprocessor macro something like "_UUID", which we
> would use as follows:
>
> constexpr uint128_t myuuid = _UUID;
>
> which the preprocessor would turn into:
>
> constexpr uint128_t myuuid = 11223344556677881122334455667788u;
>
> (Method No. 2) A constexpr function in the "std" namespace which you
> would use as follows:
>
> constexpr uint128_t myuuid = std::uuid();
>
> Now here's the next thing to address: How do we get the preprocessor /
> compiler to generate the same UUID every time? Well I think the random
> number could be generated from six items of data which we can use for
> this:
>
> Datum No. 1: The name of the current source file
> Datum No. 2: The name of the current header file (if applicable)
> Datum No. 3: The contents of the current source file
> Datum No. 4: The contents of the current header file (if applicable)
> Datum No. 5: The count of how many times _UUID has already been
> used in the current source file
> Datum No. 6: The count of how many times _UUID has already been
> used in the current header file (if applicable)
>
> All six data can be piped into something like the MD5 hash function to
> give a 128-Bit digest.
>
> Plus we would have to discuss what exactly is supposed to happen in a
> scenario such as the following. Let's say we have a header file as
> follows:
>
> [beginning of header file]
> constexpr uint128_t myuuid = std::uuid();
> [end of header file]
>
> A const (or constexpr) global variable has internal linkage by
> default. So if we were to include the above header file in say, 26
> different source files, then should all 26 source files see the same
> 128-Bit number? What if we're building on MS-Windows and one file is
> "myheader.hpp" but gets seen as "MYHEADER.HPP"?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>