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-10 13:10:02

> Message du 10/05/11 13:02
> 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 : "Stewart, Robert"
> >
> > > > > 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 fist is more on the line of functional paradigm. The
> > > > second on the procedural one. I understand that the
> > > > procedural one can be more efficient, but the functional
> > > > one separates clearly what are the in a,d the out
> > > > parameters. Are both alternatives exclusive?
> > >
> > > They aren't exclusive, but they'd need different names and,
> > > again, I suspect we'd be getting into the too-many-choices
> > > conundrum.
> >
> > Couldn't overload be used here?
> 
> It could. However, there are two issues. First, note that the second doesn't require the target type template parameter because of the second argument. Second, we're back to the discussion that a "try_" function not returning bool. You've noted that optional offers the safe-bool implicit conversion, of course, but these issues will probably cause concern if not confusion.
> 
> Recall that the optional returning version can be written as convert_cast>(s) (or convert_to>(s)). Doing so is clear, works nicely with auto, and avoids the issues with a non-bool return value and difference in template parameter treatment. Consequently, I think that's a superior approach.

Hmmm. I like the optional specialization. I need to see in the absence of auto how usable is it.

> > > > > Besides, the same thing is done with the following which
> > > > > is simpler and less tricky:
> > > > >
> > > > > int i;
> > > > > if (try_converting_to(s, i)) ...
> > > >
> > > > If conversion to bool is implicit the bool parameter will
> > > > be redundant and the preceding could be expressed as
> > > >
> > > > int i;
> > > > if ((opt_tie(i) = try_convert_to(*int*)(s))) ...
> > >
> > > Ah, right. That's a curious approach to it. You're
> > > suggesting, if I have all the parts aligned right, that
> > > try_convert_to() return optional and that opt_tie() assign
> > > to its argument iff the optional is set. That means there's
> > > an optional-based API and the following is also possible:
> > >
> > > int i(fallback);
> > > opt_tie(i) = try_convert_to(s);
> >
> > Yes this something I could use.
> 
> Note that such a function need not be named "try_convert_to." I'm not sure what other name to give it, at present, but it would be useful either way.
> 
> It appears that we're suggesting that opt_tie() be overloaded:
> 
> int i;
> bool b;
> opt_tie(i, b) = convert_to>(s);
> if (!b)
> {
> i = fallback;
> std::cerr << "using fallback\n";
> }
> 
> and
> 
> i = fallback;
> opt_tie(i) = convert_to>(s);

No. I don't think the overload with the boolean parameter is really useful and it is a little bit confusing to have both.

> Note that it seems to me that opt_tie() should be part of Boost.Optional.

Yes, of course. If at the end of this discussion we agree on the usefulness of opt_tie, we could start a new thread or contact the maintainer directly.

Best,
Vicente