What makes the Nil UUID not "valid"?
Scott, I suspect you are asking the questions you already know the answers to. Still I'll try answering them. Nil is invalid in the same way as NULL is invalid -- it does not deliver the main properties the class has been designed for. nil and NULL are specifically introduced to be different and distinguishable from normal "valid" objects. *That* makes them "invalid".
It has its own section in the RFC, and regardless of what the default constructor does, there's going to be uuids::nil() to get an instance of it.
Yes, I hope there will "be uuids::nil() to get an instance of it" and I'd like that to be the only get-nil mechanism. I thought the original discussion centered around the default constructor behavior and to me that behavior is very important what the default constructor does.
If it's "invalid", why is it still available?
It is available for the same reason NULL and -1 (for many C functions) (and many other objects designated as "invalid") are available and I really do not want to be elaborating obvoius things of that kind. Still, it does not make uuid::nill() or uuid a pointer.
Do you have some examples of other objects that do (or should) behave similarly to your desire for uuid?
int example = int(); double d = double(); std::string str; in fact probably all the classes with the value semantics.
None of those do any generation of any sort;
To me it is application-specific what any constructor does or does not, generation or no generation.
They all have T() == T();
So what? The fact that for some classes T() == T() is purely coincidental. Or is it in the Standard? I'll promptly agree/surrender if it is a Standard requirement.
And they all are rarely useful as-is.
An 0 integer and an empty string "are rarely useful as-is"? I do not understand what you mean.
I'd argue that pointers do have value semantics.
I am not sure what to say to that.
swap(int *, int *) can only swap the pointees, not the pointers themselves.
In fact, swap(int* p1, int* p2) swaps the *pointers* because after the call p1 will have the value of p2 and p2 will have the value of p1.
I'd say that the fundamental property of pointers is that, in the relevant domain, there exists an injective map from set the "pointees" to the set of pointers (the "address of" operator, for plain pointers) and a surjective map from the set of pointer to the set of "pointees" (the "dereference" operator, for plain pointer). UUIDs fit that definition. If you label each, say, database record with a UUID, there's a surjective map from the UUID to the record (with something like "SELECT ... WHERE id = @id" in SQL), and an injective map from the record to the UUID (by looking at the id field in the record).
The same concept is likely to have different meanings in different areas and on different absraction levels. My interpretation of a pointer is pretty much as Wikipedia desribes it: In computer science, a pointer is a programming language data type whose value refers directly to (or "points to") another value stored elsewhere... For me UUID does not fit *that* definition.
The point is that this is a *breaking* change in the standard unless you assume that value_type() == value_type() for every type that could be put in a std::vector in C++03. I can't think of any applicable type that breaks that assumption -- and presumably the committee couldn't either -- so I don't think that making UUID break it is a good idea.
I'd appreciate if you could clarify the following for me: Is value_type() == value_type() an assumpton you made, or is it an assumption you know the committee made or the committee stated somewhere that was an expectation or even a requirement for not following which would be a *breaking* change? Could you please indicate any documents or parts of the Standard (I could not find anything of that kind)? And what exactly "my-style" UUID is breaking? These are honest questions. We've been using "my-style" UUID quite extensively (over a year) in our project and would like to know what exactly we are breaking. Apologies that I snipped and left unanswered quite a bit of your replies. They seem to cover too many different areas/issues and I simply have no capacity to agrue of such a wide front. So, I am happy you have it your way. Best, V.