Policies must be orthogonal between themselves, but not neccesarily w.r.t the primary type(s). In fact, many common policies (from common policy-based designs) are not.
An example?
If this were not a policy, users would be stuck with the definition of the default traits class. I agree that this opens a window to all sort of problems in case a user plugs in an invalid traits, but I think that should not constitute a reason for fixing the traits into the converter. As always, "trust the programmer"
So again Trait is not a Policy and let's not mix them
I disagree. A trait can _function_ as a policy IMO.
Well, I do follow your arguments but I'm still unconvinced. A traits is type-specific, yes, but not necessarily _unique_. You see it as unique, but why would it has to be like that? It seems that that fundamental point of your argument is that traits are uniquely defined by a type, and not just a type decoration. If this were true, then I would agree, but I don't see why a type can't have a set of "compatible" traits.
Let's get back to the converter class. Do you invision somebody do something like this: struct myInt {...}the_int; struct myFloat {}; a.cpp template<> conversion_traits<myInt,myFloat> { }; boost::numeric_cast<myFloat>( the_int ); b.cpp template<> conversion_traits<myInt,myFloat> { }; boost::numeric_cast<myFloat>( the_int ); And do you think it would be good idea? How definitions in a.cpp and b.cpp could differ? Gennadiy.