Thank you for the pointers. I was able to download "Fundamentals of Generic Programming" and there they clearly consider the def. cnstr one of the fundamental operations for built-in types that they are extending on to "regular types". I have to say that my initial reaction is of a surprise. I would expect it the other way around -- I'd try making built-in types behave more like "normal" classes
? You don't get to change the way built-ins work.
Yes, I know. It was a typical statement when one gives you 2 choices when one is clearly out of question, i.e. you are in fact presented with no choice at all.
or if we cannot do that for backward compatibility reasons, then acknowledge the difference and get on with it. Dragging "normal" classes down and squezing them in to the the procrustean bed of the built-in types (dragged into the present through C compatibility) seems like a step down.
I admit I'm ambivalent about that too. The ability to cheaply default-construct an object is so seldom important, and strong invariants are so valuable, that I am reluctant to adopt the default-constructability rule.
I suspect it is worse. If a class cannot create a valid instance with a def. cnstr, then such an instance is essentially invalid, i.e. we are getting closer to the condemned "declaration without definition" behavior of the built-ins. More still, given we've open up a possibilty of incorrectly initialized object, we'll have to have additional checks throughout the code if the instance (or parts of it) is indeed valid.
However, for move semantics (and what could be more suited to that than a UUID?)
Well, actually I am not sure UUID is a really good candidate for move semantics -- it's just 16 bytes, self-contained, really cheap to copy. Move semantics makes sense for really big and expensive-to-copy objects. Still, I've been getting-by by passing by-reference or enveloped in auto_ptr or shared_ptr.
the invariant often needs to include a "empty" moved-from state anyway, and you could argue that one might as well implement a cheap, non-throwing default ctor that produces that state.
Well, from my mole-hill the medicine seems worse than the problem. If we truly need such a "special" state, I'd expect we say so explicitly and have something like foo::bad, foo::invalid, foo::uninitialized in general terms rather than hijack the def. cnstr. That way, we'd indeed mimic the "declaration without definition" built-in behavior without disrupting the status-quo. That uninitialized/invalid state could be used for the move semantics.
I am not sure of the practical importance of that Stepanov's view
Personally, I'm wary of underestimating the importance of Stepanov's views.
I did not mean to question the importance of Stepanov's view. :-) I meant to ask how big an impact that view might have for developers-practitioners. Best, V.