On Thu, Mar 13, 2025 at 1:04 PM Jeremy Rifkin wrote:
>
> > which could be either __uint128_t or std::array< char unsigned, 128u / CHAR_BIT >
>
> So you want to give implementations the freedom to return wither an arithmetic type or an array of bytes? That would make this interface very difficult to work with.


Maybe we could make it:

    std::array< char unsigned, 128u / CHAR_BIT >

or maybe even:

    std::array< char unsigned, (128u / CHAR_BIT) + !!(128u % CHAR_BIT) >

but also provide an extra constexpr function to convert the array to
__uint128_t (where a 128-Bit integer type exists).


> Again, I’m not sure why you want a 128 bit int so much.


It's commonly accepted among cryptographers, mathematicians and
computer programmers today that if you randomly generate a 128-Bit
number, then what you'll get is a sequence of bits that has never been
seen before in the universe.

If I generate a 64-Bit random number and then search through
terrabytes of BluRay discs for it, maybe I'll find it somewhere.


> > Do you think this belongs in the C++ standard library?
>
> No, but I would encourage you to make a regular library
> with this functionality. I don’t think this is a good fit for the
> standard library because it’s quite niche and there’s nothing
> to indicate such a utility would be broadly useful. Additionally,
> there are a lot of design tradeoffs here that depend on use-case.


I agree that it would be good to start out by writing a header-only
library to solve this problem, and from there perhaps suggest its
addition to the standard library.

Another thing . . . instead of having two forms of the function
"uuid", maybe it would be better to name them "uuid_compile_time" and
"uuid_run_time".