Message du 09/05/11 16:09 De : "Stewart, Robert" A : "'boost@lists.boost.org'" Copie à : Objet : Re: [boost] [review] string convert
To summarize, here's the complete API as I see it now:
1. convert::default_value customization point * Default value, if needed, when not otherwise supplied
I don't see this customization point exclusive for conversions. I will move it to the boost namespace.
2. convert::converter customization point * Non-stream-based main logic * Functor interface
Do you mean that the default behavior is a call to the conversion operator?
3. T convert::convert_cast(S) * Throws on failure unless T is convert::result * Uses convert::converter to do conversion
I prefer conversion::convert_to.
4. T convert::convert_cast(S, T _fallback) * Returns _fallback on failure unless T is convert::result * Uses convert::converter to do conversion
I prefer conversion::convert_to_or.
5. bool convert::try_converting_to(S, T & _value) * Returns false and leaves _value unchanged on failure * Uses convert::converter to do conversion
I prefer conversion::try_convert_to.
6. convert::stream_converter customization point * Stream-based main logic * Functor interface * Supports manipulators
What about streamable::converter?
7. T convert::as(S, options) * Throws on failure * Uses convert::stream_converter to do conversion
What about streamable::convert_to?
8. T convert::as(S, T _fallback, options) * Returns _fallback on failure * Uses convert::stream_converter to do conversion
What about streamable::convert_to_or?
9. bool convert::try_as(S, T & _value, options) * Returns false and leaves _value unchanged on failure * Uses convert::stream_converter to do conversion
What about streamable::try_convert_to?
Does that cover everything satisfactorily? Did I miss something? Except where I have suggested specific support for convert::result, I don't think it should be allowed. (That is, use SFINAE to ensure that convert::result isn't used with the other parts of the API.)
If try_ will return bool, I think that we need also a function that returns optional. Even if the function has the problem related to a template parameter, the name of the function don't reflect that the result will be the parameter T, and doesn't return a bloated interface, but a well know and useful class that I believe is proposed for TR2, or if it is not the case it should be.
If that's a decent API, and since it represents the combination of the functionality in both Vicente's and your library, perhaps the two of you could collaborate on it and produce a new Boost.Convert proposal. (I'd prefer Boost.Convert to Boost.Conversion because the namespace name is shorter and more useful when reading names like "convert::as.")
The names I have suggested allow to have two more or less independent libraries, that follows the same interface on the common needs, but having a different default behavior. For the specific stream conversions there are surely a lot of variants that can be provided. I recognize that the namespace streamable is not perfect. If we find a better one, Robert, Vladimir what do you think of this proposal? Best, Vicente