I agree with the observation. A motivation has always been a weak point of this kind of proposal.
Do you know what is better than a UUID?
Not needing one.

You need a problem that it is worth solving before coming up with a solution.

Not just "I have an idea that sounds cool and has never been done before, let's do it", absent a technical need. If it sounds cool and it hasn't been done before, there's probably a reason for it.


________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]>
Sent: Thursday, March 13, 2025 8:06:18 PM
To: std-proposals_at_lists.isocpp.org <std-proposals_at_[hidden]>
Cc: Jeremy Rifkin <rifkin.jer_at_[hidden]>
Subject: Re: [std-proposals] Random numbers in identical builds

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

But what if it doesn’t exist? Then you haven’t solved the fundamental problem with this interface.

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

This is a bold claim and it’s wrong. 128 random bits can provide *at most* 64 bits of collision resistance thanks to the birthday paradox. 2^64 is large, but not that large.

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

I think you missed the other part of what I said, which is that you can use two random 64 bit numbers to make a random 128 bit number. Similarly, you can use four to make a random 256 bit number. Let the user decide how much they need for their use case, don’t try to force 128 bit ints for no reason.

But you’re also not spelling out what exactly you’re trying to solve and what your use case is. First you’re talking about UUIDs then you’re saying you really just mean random numbers but are calling them UUIDs now you’re back to saying you want them to be universally unique.

You need to be very specific about what problem and use cases you’re trying to solve here of you want any hope of solving them or convincing people that they are worth solving.

Cheers,
Jeremy

On Thu, Mar 13, 2025 at 11:17 Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
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".
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_lists.isocpp.org>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals