Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk