If user do not like default value for the trait. It's value should be set *externally* to the component definition. That is the major point I am trying to prove in regards to numeric_cast design and in thic generic discussion.
But what about the distinction that xxx_traits<T>, a class, is being used as the Policy type in Foo? From Foo's perspective, it has a Policy which its clients can define any way they like
They sure could. Note though that this is not how basic_string is designed. There Traits parameter used as trait collection. I am yet to see an example of good design that rely on possibility of trait class to be used sometimes as policy. I still couldn't find a reason to use policy parameter that could be instantiated with trait value. It should be something that is not unique to the type but sometimes it may coinside with some other [un]related type trait. I guess it's possible. But it rare case that could be omitted in basic definition and mentioned only in "special cases" clause.
within the constraints of what's expected of the policy. By the same token, other code, even code within Foo can use xxx_traits<T> to get information. (Foo could do it regardless of the type corresponding to the template argument Policy.)
-- Rob Stewart stewart@sig.com
Gennadiy.