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

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Pierre T. (ptalbot_at_[hidden])
Date: 2013-04-20 08:44:34

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

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

> 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.
Should we use boost::variant to facilitate the C++98 variant 
implementation ?

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

> 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);

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

I'll send soon my proposal to the boost mailing-list for any 
reviews/comments.

Thank you,
Pierre Talbot.