Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?

Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-11-26 05:08:55

On November 26, 2014 2:12:56 AM EST, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
>Le 26/11/14 06:26, Vladimir Batov a écrit :
>> Vicente Botet wrote
>>> ...
>>> Following your reasoning, I will suggest to remove the implicit
>>> construction from T to optional
>>> <T>
>>>   and/or remove the
>>> operator<(optional
>>> <T>
>>> , optional<>).
>>
>> Vicente, you are not serious, right?..
>
>Vladimir, yes and not. Were talking of the possibility of a new 
>safe_optional. I would like we explore how we would like to have this 
>new type.

[snip]

>I'm looking on how all these conversions can be made safer.

[snip]

>The idea is to state explicitly that you want a explicit conversion but
>don't state to what. The what is deduced from the context. 

That idea is rather odd to me. One is hardly being explicit if one is relying on context to determine the target type.

>Let me represent by
>
>[ x ]
>
>this explicit conversion to the context.
>With this we could be able to
>
>   optional<int> f(int x) {
>     if (x<0)
>         return nullopt ;
>     }
>     return [ x ];
>    }
>
>[ x ] is longer than x but shorter than make_optional(x).
>
>The meaning of
>
>    return [ x ]

The target type is reasonably deduced to be the function return type, so this is a means to avoid repeating the type. auto would work as well: return auto(x);. That's on keeping with auto's purpose.

>on the context of a function returning M would be given by
>
>   return M(x);
>
>We could also add an indirection and translate it to
>
>   return make_explicitly(type<M>{}, x);
>
>or
>
>   return type<M>{}[x];
>
>where the type<M> instance is used only to be able to overload on M.
>
>    template <class T>
>    struct type {};
>
>The default implementation could then be a call to the explicit 
>constructor of the context from the parameter
>
>   // default to explicit constructor
>   template <class M, class X>
>   M make_explicitly(type<M>, X && x) { return M(std::forward<T>(x)); }

Using auto would be simpler.

>We could stop here or we could use [ x ] not only on a return statement
>
>but also in any expression as in
>
>    optional<int> oi;
>    int x;
>    ...
>    if ( oi < [x] )
>       ....
>
>Note that we don't need an implicit conversion from T to optional<T> 
>then but only an explicit one, avoiding the more verbose
>
>   if ( oi < std::make_optional(x) )

If anything in the expression or calling context changes, the target type can change. How is that explicit? It's no better than an implicit conversion. Indeed, it's worse: it bypasses the control implied by marking a constructor explicit.

>This can be applied also on the context of the await proposal to 
>separate the concerns. await will take care of the the continuation
>part 
>and {{}} will take care explicit conversion transformation.
>
>future<int> f(int x) {
>   if (x > 10)
>     return await something_long(x);
>   else
>     return [ x + 1 ]; // make_ready_future
>}

Use auto for the return statement.

>This operator could be used also to mean the empty set, as in
>
>set<int> f {
>
>   ...
>   return [];
>};

This is just default construction. How about auto() or auto{}?

>Another example
>
>variant< int, string> f(int x) {
>   if (x > 10)
>     return [ std::string("___") ];
>    else
>     return [ x + 1 ];
>}

These are return statements, so just use auto here, too.

___
Rob

(Sent from my portable computation engine)