[Lldb-commits] [PATCH] D40537: Simplify UUID::IsValid()

[Zachary Turner via lldb-commits]

On Tue, Nov 28, 2017 at 10:18 AM Greg Clayton <clayborg at gmail.com> wrote:

> On Nov 27, 2017, at 10:11 PM, Zachary Turner <zturner at google.com> wrote:
>
> As an aside, I don't really like this class.  For example, You can
> currently assign a UUID[16] to a UUID[20].  That doesn't make a lot of
> sense to me.
>
>
> What about an invalid UUID[0] being assigned with a valid UUID[16] or
> UUID[20]? Why doesn't this make sense? I don't follow.
>

Nothing is invalid, I just think it's better and expresses the intent more
clearly if you can only assign between UUIDs of the same size.  For
example, If the UUID class were templated on size, then there would not
even be such thing as a UUID[0] or a "universally invalid UUID".  There
would be an "invalid 16-byte UUID" and an "invalid 20-byte UUID", and those
would be different things.


>
>
> As a future cleanup, I think this class should probably be a template such
> as UUID<N>, and then internally it can store a std::array<uint8_t, N>.  And
> we can static_assert that N is of a known size if we desire.
>
>
> UUID values are objects contained as members inside of other objects. They
> all default to start with no preconceived notion of what the UUID should
> be. IMHO the UUID class is just fine and needs to be able to represent any
> UUID, from empty uninitialized ones, and be able to be assigned and changed
> at will.
>
>
Is there ever a use case for changing the number of bytes in a UUID?  If
you're working with 16-byte UUIDs, does it ever actually happen that now
you have a 20-byte UUID?  Can you imagine a use case currently where an
N-byte UUID is being compared against an M-byte UUID in a real-world
scenario?  If the answer is no, then it may as well be enforced by the
compiler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20171128/31e01e53/attachment.html>