Message du 09/05/11 21:07 De : "Stewart, Robert" A : "'boost@lists.boost.org'" Copie à : Objet : Re: [boost] [convert] no-throw and fallback feature
Vicente BOTET wrote:
De : "Stewart, Robert"
Vicente BOTET wrote:
De : "Vladimir Batov"
From: "Vicente BOTET"
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.
Perhaps so.
There is something that I like of the function returning optional.
get_value_or() makes it useful nice. optional has good semantics for what we're trying to do. The safe-bool conversion is not unreasonable, but it does suffer from the implicit conversion issue WRT template type deduction.
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);
I thought about that briefly at one point in the discussions.
the main problem of this prototype is that target must be copied and a default value is needed when the conversion fails.
The extra copy is not desirable when there are reasonable (or, at least, not unreasonable) alternatives to avoid it.
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);
I presume that no assignment would be done to i if b is false.
That actually means writing this:
int i; bool b; ctie(i, b) = try_converting_to(s); if (!b) { i = fallback; std::cerr << "using fallback\n"; }
Compare that to this:
int i(fallback); if (!try_converting_to(s, i)) { std::cerr << "using fallback\n"; }
The optional returning version provides useful benefits like no extra copy, get_value_or(), and no instance of the target type if the conversion fails.
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)) ...
Interesting, but probably too much of a good thing.
Besides, the same thing is done with the following which is simpler and less tricky:
int i; if (try_converting_to(s, i)) ...
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, ...
Current policy is to put nothing directly into the boost namespace. Perhaps that can be relaxed, but don't count on it.
I know that the policy is to try to avoid it. I will add a namespace for Boost.Conversion to avoid discussing on this subject, but I really think that in this case it is better to don't use a specific namespace.
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.
You don't think "convert" is a good choice?
I would prefer to use a noun for namespace, then an adjetive and in the last instance a meaningless name, like spirit. I have never used a verb as namespace. The same applies to classes. For me convert stands for a function, converter for a class, convertible for an interface and conversion for a namespace. I'm sure you agree with me on this common usage.
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.
Do you mean you like the name, in contrast to my argument against it above, or that you like the function?
The name. boost::convert_to_or() or boost::conversion::convert_to_or() are good for me. Best, Vicente