But there's always the other way to resolve a disagreement over semantics: parametrization!
could be overloaded to call lexical_cast<uuid<aggregate> >, the fastest option. People could have map<string, uuid<nil_default> > if
What if there was an initialization policy? boost::uuid could be boost::uuids::uuid<no_default>, since I think there are a fairly large number of use cases that don't need one at all. lexical_cast<uuid<T> they want the "if (m[foo])" shortcut. And you could have uuid<native_generator>.
It's got me thinking about uuid parametrization and I think there is part of it that I am warming up to and the other part that I am unsure of. What I think we indeed could parameterize on might be the generator, i.e. template<class Generator> uuid { ... }; Reasoning behind it is that it is probably most likely that the developer once chosen a particular generator will stick with it throughout its application rather than juggling different generators at run-time. Therefore, parameterizing of the generator seems to make the code more solid and easier to maintain as the variability (and the room for an error -- calling the wrong generator) out of the equation. The "bad" thing is that this seem to better fit the def. cnstr (with generating behavior): template<class Generator> uuid { typedef ... nil_type; static nil_type nil; uuid() { typename Generator::range range = Generator::generate(); this->initialize(range.begin(), range.end()); } uuid(nil_type) { for (boost::array<char, 16>::iterator i = data.begin(), end = data.end(); i != data.end(); *i = 0, ++i); } }; As for parameterization of policy, then I am honestly not sure. As a proof of the concept it indeed sounds good. My fear though is that for maintainability/readability purposes that might be a nightmare. Having said that, that my view about hte def. cnstr and its behavior is just my view. If there is a good number of people thinking that the def. cnstr wih the nil behavior might be better/more practical, we should adapt the view, clearly document that and move forward. The certainly good part of it it'll make a lot of things easier to implement. Best, V.