Re: UUID design discussion

From: Rainer Deyke (rdeyke_at_[hidden])
Date: 2024-04-26 10:27:40

On 25.04.24 16:33, Peter Dimov via Boost wrote:
> We've been discussing some UUID design issues in, well,
> issues in the Uuid repo, namely
> 
> https://github.com/boostorg/uuid/issues/96 and, for context,
> https://github.com/boostorg/uuid/issues/113.
> 
> This topic might be of wide interest to developers, so I thought
> it would be better to have this list know about it.
> 
> Anyone who has an opinion on the matter is welcome to express
> it in the issue, or here.
> 
> In addition to the questions raised in #96, namely, how should the
> constructors and the accessors of `uuid` look like (once we somehow
> move away from the public `data` member), here are some more
> topics of interest:
> 
> * Should a default-constructed `uuid` remain uninitialized, or should
>    the default constructor produce the nil Uuid? (Uninitialized is not
>    a good look in 2024 because safety. On the other hand,
>    `new uuid[ 1048576 ]` will start doing a `memset`.)

Initialize it.  I can't imagine producing enough UUIDs that the 
performance cost of initialization could be significant.

> * At the moment wide strings are processed by the name generators
>    by converting every wchar_t to 32 bit, then hashing the bytes, zeroes
>    and all. This doesn't strike me as correct. I think that the string should
>    be converted to UTF-8 on the fly (with 32 bit wchar_t assumed UTF-16
>    and 32 bit wchar_t assumed UTF-32.)

When creating a UUID from a name instead of by a random process, the 
same input name is guaranteed to produce the same output UUID.  Silently 
changing the current behavior breaks that guarantee, which can break 
user code.  Better to either completely remove wchar_t support or to 
leave the current behavior in place.

-- 
Rainer Deyke (rainerd_at_[hidden])