Re: [boost] [gsoc-2013] Boost.Expected

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-20 09:14:15

Le 20/04/13 14:44, Pierre T. a écrit :
> On 04/20/2013 11:36 AM, Vicente J. Botet Escriba wrote:
>> Le 20/04/13 10:50, Vicente J. Botet Escriba a écrit :
>>> Le 19/04/13 16:36, Pierre T. a écrit :
>>>> On 04/13/2013 12:57 PM, Klaim - Joël Lamotte wrote:
>>>>> On Sat, Apr 13, 2013 at 8:38 AM, Pierre T. <ptalbot_at_[hidden]> 
>>>>> wrote:
>>>>>
>>>>>
>>>> Hello,
>>>>
>>>> I gave a try at the implementation of the expected_or_error class.
>>>> I used the boost layout to package the implementation, you can 
>>>> download it here : http://www.hyc.io/boost/expected.zip
>>>> Finally, feel free to explore the documentation I wrote 
>>>> http://www.hyc.io/boost/index.html
>>>>
>>>> Please, do not hesitate to give me advices and critics to improve 
>>>> this library and my future proposal.
>>>>
>>>>
>>> Hi,
>>>
>>> glad to see you are exploring the different alternatives. This is 
>>> really a good starting point.
>>>
>>> Now it is time to make a concrete proposal for you candidature.
>>>
>>>
>>
>> Hi again,
>>
> Hi,
>> I have some questions:
>>
>> Do you think that expected and/or expected_or_error could/should have 
>> value semantics, that is define operator==?
> I don't have any use cases where expected/expected_or_error would have 
> value semantics.
> Even if the underlying value has value semantics, you can't compare 
> exceptions and you rarely compare two error code encapsulated into two 
> variables (of course you often compare a variable and a constant error 
> code).
> So, unless we give me good arguments, I would consider it as entity 
> semantics.
I was wondering as optional<T> has value semantics and no value is 
different from any optional valued. I don't know yet if it has a sens to 
define it for expected_or_error and you are right we need a valid use case.
>
>> I don't know if the const get function should be provided?
>>   const T& get() const { return value; }
>> what do you think?
> Because expected<> aims to always be a return value, I would be say we 
> don't need it.
> Nevertheless, the user could pass expected to a function by const-ref. 
> So to enable any programming style, I would let it there.
Sorry, I meant the non-const. Anyway, I guess that it is there to make 
easier to pass a non-const to a function expecting a T&.

expected<T> r =f();
g(r.get());
>
>>
>> What about an explicit conversion to the underlying type that behaves 
>> as the get function?
> Is there really an interest to do (type)e instead of e.get() ? I'm not 
> sure. However I don't have any arguments against it.
>
>> What about an explicit conversion to bool that behaves as the valid 
>> function?
> Yes, even an implicit conversion to bool could be useful.
Hrrr, no please no implicit conversion.
After comparing with optional,  the problem could also be what the user 
could expect from

expected<bool> b = f();
if (b) {...}
>
>> Do you pretend to provide a C++98 portable implementation?
> I'm pretty sure it's possible with some features disable such as the 
> move semantics.
I would not be able to use it if Boost.Move is not supported.
> Should we use boost::variant to facilitate the C++98 variant 
> implementation ?
I don't know if boost::variant supports move semantics. I don't think it 
is worth adding this dependency, but maybe I'm wrong.
>
>> How the expected_or_error behaves in the presence of copy constructor 
>> exceptions?
> It doesn't capture the exception and the responsibility of handling 
> this exception is delegated to higher layer.

Stating clearly this behavior in the proposal would be appreciated.
>
>> Which expected_or_error<> functions can be declared as noexcept?
>
> Constructor/operator=: noexcept if the T/ErrorType copy/move 
> constructor doesn't throw.
> Destructor: noexcept if the T/ErrorType destructor doesn't throw.
> Swap: noexcept if the move constructor(c++11)/ copy constructor(c++98) 
> doesn't throw.
>
> Observer and getter can be declared as no except.
>
>> Which expected<> functions can be declared as noexcept?
>>
> Same as above plus:
>
> noexcept:
> fromException(std::exception_ptr p);
> fromException();
> fromCode(F fun);
>
Could you add them to the scope of the proposal,
BTW, could you rename the camelCase function to the usual Boost style, 
e.g. from_exception. Note that I have removed these functions and 
replaced them as non-member factories.
What do you think?

>> Best,
>> Vicente
>>
> Your questions are interesting and I'm not sure I gave the best answers.
> Some of the design decisions are hard to guess without any feedback 
> from users (such as the value semantics).
>
> I like your implementation of expected, the "then" method is similar 
> to what I tried to achieve with "resolve".
> Maybe we could have a method "otherwise" which do the same than "then" 
> but with the error ?
Yes sure. It would be great to explore it with specific examples.
>
> I'll send soon my proposal to the boost mailing-list for any 
> reviews/comments.
>

Great,
Vicente