Subject: Re: [boost] [convert] no-throw and fallback feature
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-05-09 13:45:19
> Message du 09/05/11 17:14
> De : "Stewart, Robert"
> A : "'boost_at_[hidden]'"
> Copie à :
> Objet : Re: [boost] [convert] no-throw and fallback feature
>
> Vicente BOTET wrote:
> > De : "Vladimir Batov"
> > > From: "Vicente BOTET"
> >
> > > > I was thinking on the fallback feature a little bit more
> > > > and I've the impression that we can get it for free. If we
> > > > accept that we need a no-throw function such as
> > > > try_convert_to that returns an optional Target we can have
> > > > the fallback using the optional::get_value_or function
> > > >
> > > > auto r = try_convert_to(*int*)(s);
> > > > int i = r.get_value_or(fallback);
> > > > ...
>
> The issue raised before is that "try" indicates a bool return type. Perhaps "maybe_as" would work?
>
> auto o(convert::maybe_as(s));
>
> However, I do like the use of get_value_or().
I remember this point. The fact that optional is implicitly convertible to a safe bool let me think that try_ is ok. But if a better name is found I would adopt it.
There is something that I like of the function returning optional. But I will first comeback to the prototype that returned a pair Target,bool. As a pair is considered as a tuple we can write
tie(i,b) = convert_to(s);
the main problem of this prototype is that target must be copied and a default value is needed when the conversion fails. If we see optional as a kind of conditional tuple and we imagine something like a conditional tie (let me call it 'ctie'), we could be able to write
ctie(i,b) = try_convert_to(s);
We could also write,
if (ctie(i,b) = try_convert_to(s),b ) ....
If in addition the result of ctie is implicitly convertible to bool, we can have
if ((ctie(i,b) = try_convert_to(s)) ...
Sorry for the digression.
> > > > I don't know if it is worth adding a function that does all
> > > > in one
> > > >
> > > > int i = convert_to_or(*int*)(s, fallback);
>
> Don't forget the name when in its namespace and with the type specified clearly: convert::convert_to_or(s, fallback). The repetition of "convert" is not ideal, but no different than "convert_cast" and stands up well with a using declaration or directive. Unfortunately, "to_or" isn't right. It suggests something other than int is the desire.
Boost.Conversion defines all these operations at the boost namespace level, as it is done for the other generic cast, lexical_cast, numeric_cast, polymorphic_cast, ... I agree that we should use as specific namespace for each library, but we the operations are generic it is IMO desirable that these functions stay on the boost namespace. If I was forced to add a namespace I will of course choose conversion.
> I can't think of a good name, so I'm inclined to reject this function. If a better name arises, I can certainly see some value in including such a function, but at some point, there get to be too many ways to do a thing and that, itself, confuses matters. Thus, this function must be considered in light of the entire API.
I like convert_to_or, I don't think it is absolutely needed, but it could be added without too much noise.
Best,
Vicente