Hi,
To add something like this to the standard I think would require a ton
of justification. Especially given that it can be implemented fairly
easily already by yourself. The set of semantics you have laid out
aren't desirable to everyone so arguably it's better implemented bespoke.

I'm sorry to nitpick but:

> People want random numbers at compile time that stay the same if they
> hit "Rebuild" but which are still sufficiently random.

Who?

> I'm still going to go with 128-Bit random numbers

Why? Why not provide something more straightforward and let the user
make a 128-bit random number if they want one?

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

If what you want is a random number, call it a random number. Don't call
it a UUID as it's not a "universally unique identifier" in any way (it's
not universal, it's not unique, and it's not an identifier).

> (Method No. 1) A preprocessor macro something like "_UUID", which we
> would use as follows:

It would probably be __UUID__, for consistency. This has come up on the
mailing list before, namely when I was discussing standardizing __COUNTER__.

> (Method No. 2) A constexpr function in the "std" namespace which you
> would use as follows:

This would generally be preferrable in the modern push of "constexpr
everything." And in general macros are a big code smell.

> Datum No. 1: The name of the current source file
> Datum No. 2: The name of the current header file (if applicable)

These are the same thing, at least as far as __FILE__ and
std::source_location are concerned.

> Datum No. 3: The contents of the current source file
> Datum No. 4: The contents of the current header file (if applicable)

I would *highly* recommend against doing deterministic RNG or UUID
generation based on file contents.

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

This is sounding like __COUNTER__.

> All six data can be piped into something like the MD5 hash function to
> give a 128-Bit digest.

Why MD5? What guarantees do you want to make about the random number
you're providing?

> 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?

Yes, you have found an ODR violation.

> What if we're building on MS-Windows and one file is
> "myheader.hpp" but gets seen as "MYHEADER.HPP"?

Also an important pitfall here.


My advice though would be that you can already do this without language
or standard library support and it's probably better to do so. This may
change if there's any widespread desire for this sort of functionality
but I don't think there is.


Cheers,
Jeremy

On Mar 10 2025, at 10: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
>