... This is about needing to specify what the "contract" for a converter is.
In my view there is no "contract for converter"... apart from the *requirement* it is a "callable" with a certain signature.
That is indeed exactly where we disagree.
Conversion to/from string requires a different contract than conversion between types, encryption or conversion from Celsius to Fahrenheit.
I fail to see how/why these mentioned different type conversions/transformations "require different contracts".
Perhaps it is better to say 'would benefit from different contracts'. For instance: type-to-type converters would benefit from contracts that specify mechanisms for checking for reversibility, loss of precision, overflow, etc. type-string converters would benefit from contracts that specify mechanisms for giving formatting instructions unit-to-unit converters would benefit from all kinds of consistency and equivalence test... see the Boost Unit library encryptions converters would benefit from contracts that specify mechanisms to specify/query encryption strength
The user still needs to supply a Default Construction function it is just not the default constructor. I can see that this requirement follows from the stringstream implementation.
No, it's not a requirement of std::sstream but rather imposed by boost::convert::from.
Yes, but why? Isn't the underlying reason that sstream requires a reference? my_type val; stream >> val;
But it does not seem a reasonable requirement for a generic converter (nor is the requirement of Copy Constructible). All you can reasonably require is some function that creates a TypeOut from a TypeIn.
I was not able to come up with a better implementation that would not have those requirements. If you have such an implementation, I'll incorporate it gladly.
How about reducing the API to the following? The only requirement on TypeOut
would be the requirements put by boost::optional (or your closely related
result-type).
api.hpp
#include