Re: [boost] [convert] are you mixing default_value and error_value?

Subject: Re: [boost] [convert] are you mixing default_value and error_value?
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-07-08 06:42:52

----- Original Message ----- 
From: "Vladimir Batov" <vladimir.batov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, July 07, 2009 12:03 AM
Subject: Re: [boost][convert] are you mixing default_value and error_value?

> 
>> vicente.botet <vicente.botet <at> wanadoo.fr> writes:
>> I have read the documentation and I think that you are mixing default
>> value with error value. 
> 
> I am not sure I can agree. In my book there is *no* separate default value.
> There is only one value -- the conversion-failure (called default, error, etc.)
> value. 
> 
>> The fact that a
>> type is not DefaultConstructible do not implies that the user
>> wants to have an exception when the
>> conversion fails. This are two orthogonal dimensions. 
> 
> I think you are saying that "The fact that a type is not DefaultConstructible
> does not mean that the user *does not* want to have an exception when the
> conversion fails" because when the default/error value is provided, there is
> *no* exception on failure.

Yes, this is what I wanted to say. On the case of the direction class, you are forced to give an *initial value* because direction is not default constructible, but with your interface we can't have an exception in this case. Is for this reason I say you are mixin both.
 
> And indeed, I strongly agree that these two issues -- the throwing behavior and
> providing/not-providing the default/error value -- are indeed orthogonal. I am
> very glad you mention that because IMHO it is a subtle but important issue that
> is often missed or misunderstood.

So, do you plan to separate them?
 
>> I think that for these non Default constructible types you can use
>> a trait that gives you a default value for
>> types not having a default constructor. E.g.
>> 
>> template <typename T> 
>> struct default_value_trait {
>>     static const T value=T();
>> };
>> 
>> template <> 
>> struct default_value_trait<direction> {
>>     static const direction value=direction::up;
>> };
>> 
>> So now you don't need any more to pass the default value as 
>> parameter, and the following should compile
>> 
>> direction dir = convert<direction>::from (str);  
>> 
>> and could  throw if conversion fails after minor modification
>> on the implementation.
> 
> Yes, it is an interesting approach and I like it as it allows to deploy throwing
> 'convert' uniformly for DefaultConstructible and NonDefaultConstructible types.
> The only hesitation that pops to my mind is that I feel 'convert' is fairly
> straightforward and needs to be used without much/any preparation. (That's how I
> tend to use it anyway). That's why I was whining about the named parameters'
> interface as it requires a round trip to the top of the file to add 'using'. If
> lazy-me has to do the same for the default_value_trait<direction>
> specialization, then I'll probably try avoiding that. 

This is surely because you are mixing the returned value when a failure occur and the initial value when the class is not default convertible.

> On the other hand,
> integration of a Type into the lexical_cast/convert framework does require some
> preparation -- namely op>>() and op<<().  We could keep it for backward
> compatibility but might offer a new trait-based way of integrating a Type into
> the lexical_cast/convert framework. Like
> 
> template<>
> struct convert_trait<Type>
> {
> }
> 
> where we might put anything related to the integration of the Type into the
> convert framework. Is it too far-fetched? Thinking aloud really.

Why not?
 
>> I suppose you can reach the same effect with the error_value
>> needed when the user want no_thow semantics.
>> 
>> template <typename T> 
>> struct error_value_trait {
>>     static const T value=T();
>> };
>> 
>> template <> 
>> struct error_value_trait<direction> {
>>     static const direction value=direction::down;
>> };
>> 
>> So the following 
>> 
>> direction dir = convert<direction>::from (str)(_thows=false);  
>> 
>> will return direction::down when conversion fails after
>> some modification on the implementation
> 
> That feels over-engineered. Somehow I feel more comfortable with more explicit
> 
> direction dir = convert<direction>::from(str, direction::dn);  

You are right the failure returned value should be given at the call. What about  passing it statically
    direction dir = convert<direction, no_throws<direction::dn> >(str);  
or dynamically
    direction dir = convert<direction>(str, (_no_throws=direction::dn));  

>> One more question raise now. Should the fact the conversion throws
>> or not when failing be part of the
>> function type or a function parameter?
>> 
>> Do we need 
>> 
>> direction dir = convert<direction, no_thows<> >::from (str);  
>> 
>> or 
>> 
>> direction dir = convert<direction>::from (str)(_thows=false);  
> 
> Yes, that's a fair question. I considered convert<Type, Throw> before and back
> then it seemed that it was more flexible to configure the throwing behavior via
> a parameter. 

Have you considered to return failure setting errno? How can your current interface be adapted to this use case?

With a coverter template parameter you can do something like: statically
    direction dir = convert<direction, set_errno<EINVALID> >(str);  
or dynamicaly
    direction dir = convert<direction>(str, (_set_errno=EINVALID));  

> Having convert<Type>::result played a role as well.

Have you considered to convert returns just a pair<T, bool> or optional<T>? How can your current interface be adapted to these use cases?

With a template parameter you can do something like

pair<direction, bool> dirp = convert<direction, return_pair >(str);  
optional<direction> opt_dir = convert<direction, return_optional >(str);  
or
pair<direction, bool> dirp = convert<direction>(str, _return_pair);  
optional<direction> opt_dir = convert<direction>(str, _return_optional);  
 
> To me, in principle, there is no much difference between supplying a parameter
> as a template or as an argument. So, I chose the one that looked less
> restrictive and scaled better. Do you feel the template-based could do better? 

Templating the convert function with a converter parameter allows to have different return types that depend on the converter parameter. 

A model of converter is the functor class realizing the conversion using the conversion parameters
template <typename To>
struct converter {
    typedef related to To result_type;
    converter();
    converter(converter_parameters<To> const&);
    template <typenam From> result_type operator()(From);
};

The convert function can return the out type  (To) instead of the internal converter which is implicitly convertible to the To type.

template <typename To, typename Converter, typename From >
Converter::retult_type convert(From f, Converter const&cv) { 
    return cv(f);
}
 
>> Resumein, I think these modifications are important, 
>> so the convert function can have always only the From
>> parameter, and the throw semantics is preserved for non
>> DefaultConstructible types.

Rectification, the convert function can have two parameters, first the >From type and second the converter (parameters). The converter class must define operator()(From).
 
>>From my usage pattern I do not think I want "the convert function to always have
> only the From parameter". In fact, truth to be told, for me it is the other way
> around -- I *never* use the convert function with only the From parameter. :-) I
> prefer having the failure value immediately visible as in the following (typical
> for my usage) example:
> 
> int v = convert<int>::from(s, MAX_INT);
> if (v == MAX_INT) conversion failed.

What about
    int v = convert<int>(s, _no_thows=MAX_INT);
    if (v == MAX_INT) conversion failed.
 
> convert<direction>::result d = convert<direction>::from(s, direction::up);
> if (!d) conversion failed.

And 

optional<direction> d = convert<direction>(str, _return_optional );  
if (!d) conversion failed.
 
> That said, convert_trait seems tempting. What others think?

We can see 

_no_thows=MAX_INT
_return_pair
_return_optional

and the other parameters as elements of a DSL configuring the conversion. 

This view of the convert function with a converter parameter joins a little bit the one proposed by Hartmut in a recent post. What others think?

Best,
Vicente