In most part proposed design looks reasonable. I have only one major IMO concern.
Issue: (Major) Why traits are template parameter of converter? I've expressed my opinion in the matter before: Traits - as name suggest could not be policy. IOW should not be template parameters. Traits are type specific and an ability to supply them independently to the primary type in most cases leads to invalid/too complicated design. Traits are not only template parameters of public converter class but many other classes. IMO all of them should use S and T as template parameters instead.
I have to disagree. Traits are used as policies in too many designs, including the STL itself, and I don't see a problem with that. I agree
I don't say I like it either. Major issue with basic_string design IMO is that char_traits is template parameter
that traits classes are type specific, but they are used as policies precisely because of that: if the user of a parametrized facility wants a different treatment for a given type, she can't change *the* traits for the type, all she can do is pass in a different traits as a policy.
Here is how I see it. Trait is something type specific, IOW specific to type, IOW uniquely defined by type. If you could provide trait along with the type as a template parameter, that mean you could change it independently from the type, IOW you could define different value for trait still using the same type. For example if you have component C defined like: template<typename T, typename Trait> struct C { ... }; You could instantiate it like C<MyT,TraitValue1> or C<MyT,TraitValue2>. So as you could see trait value is not uniquely defined by the type. Proper design would be to have trait stand alone class, like this: template<typename T> struct Trait { value = ... }; template<typename T> struct C { here we are using Trait<T>::value, where we used to use Trait. }; Now if the user needs to define trait value (or change from using default value provided by most traits designs), she just need to define explicit/partial specialization for this type or types family. On the other hand policy is something that is orthogonal to the primary type (actually in policy based design there may not be any primary type, but just an orthogonal policies), IOW you could use different policies in conjunction with the same type. And natural place for the policy is along with type in component definition among the template parameters.
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
4. converter<>::convert converts only rvalue. Why? IMO we need second operation that works with lvalues. What if I want to convert int& into char&? This requires the target lvalue as a parameter instead of a return value. It could be done yes, but I don't see the reason. Why would want to do that?
For example for [de]serialization solutions. What is in your opinion is problem domain for numeric conversion? Gennadiy.