On November 26, 2014 2:12:56 AM EST, "Vicente J. Botet Escriba"
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
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)