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

Subject: Re: [boost] [convert] no-throw and fallback feature
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-09 15:06:00

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<int>(s);
   if (!b)
   {
      i = fallback;
      std::cerr << "using fallback\n";
   }

Compare that to this:

   int i(fallback);
   if (!try_converting_to<int>(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<int>(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 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 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?

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com





IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.