Re: [boost] Boost.Convert. Take 2.

Subject: Re: [boost] Boost.Convert. Take 2.
From: Vladimir Batov (vb.mail.247_at_[hidden])
Date: 2014-02-21 03:25:23

Rob Stewart <robertstewart <at> comcast.net> writes:
> On February 20, 2014 5:48:18 PM EST, Vladimir Batov <Vladimir.Batov <at>
constrainttec.com> wrote:
> >On 02/21/2014 02:47 AM, Andrzej Krzemienski wrote:
> >>
> >> Regarding "Type Requirements" section in documentation:
> >> TypeOut needs to be
> >>
> >> *Copy Constructible.*
> >> Is it not enough to require that TypeOut be *MoveConstructible*?
> > ...
> >Still I suspect some interfaces require to be Copy Constrictible. For 
> >example,
> >
> >template<typename TypeOut>
> >struct boost::convert<TypeOut>::result
> >{
> >     ...
> >     template<typename FallbackType>
> >     out_type value_or(FallbackType const& fallback) const
> >     {
> >         return good_ ? value_ : fallback;
> >     }
> >};
> 
> This would address your concern:
> 
> if (good_)
> {
>    return std::move(value_);
> }
> else
> {
>    return fallback; 
> }
> 
> However,  for non-movable types,  the fallback is to copy anyway,
> so both should be moved. 

The problem is, I think, with

>    return std::move(value_);

because it destroys "value_" which in general terms I do not think we can
do. For example, (I'll use tr1::optional instead of convert<T>::result):

tr1::optional<std::string> res = convert<std::string>::from(12345, cnv);
std::string str = res.value_or("bummer");

... if value_or() moves/destroys the string inside "res",
... then "res" is not usable from here downwards
... it's a problem, isn't it?