Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-05-09 16:52:18

> Message du 09/05/11 16:09
> De : "Stewart, Robert" 
> A : "'boost_at_[hidden]'" 
> 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