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@eldwood.com)