Re: UUID design discussion

From: Rob Boehne (robb_at_[hidden])
Date: 2024-04-25 14:42:37

From: Boost <boost-bounces_at_[hidden]> on behalf of Peter Dimov via Boost <boost_at_[hidden]>
Date: Thursday, April 25, 2024 at 9:34 AM
To: boost_at_[hidden] <boost_at_[hidden]>
Cc: Peter Dimov <pdimov_at_[hidden]>
Subject: [boost] UUID design discussion
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`.)

A memset is a very small price to pay for memory safety in cases where the caller didn’t take the care to specify.

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

To my thinking – a string should just be treated as binary data and it should not have its encoding changed – this should also make less work.