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 18:18:44

> Message du 09/05/11 23:40
> 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:
> >
> > > > 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);
> >
> > ctie will left i unchanged if b is true.

if b is false.

> ctie won't change i if the conversion succeeds?
> 
> > > I presume that no assignment would be done to i if b is
> > > false.
> 
> Surely that is the right interpretation.

Yes. 

> > > 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 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?

> > > 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. 

Best,
Vicente