Message du 09/05/11 17:14 De : "Stewart, Robert" A : "'boost@lists.boost.org'" 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