Re: [boost] [convert] no-throw and fallback feature

Subject: Re: [boost] [convert] no-throw and fallback feature
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-05-09 15:45:08

> Message du 09/05/11 21:07
> De : "Stewart, Robert" 
> A : "'boost_at_[hidden]'" 
> 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