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

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Pierre T. (ptalbot_at_[hidden])
Date: 2013-04-20 14:45:13

On 04/20/2013 03:14 PM, Vicente J. Botet Escriba wrote:
> 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.
Do you say there is a sens to define it for expected ? How do we compare 
two exceptions ?
>>
>>> 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) {...}
Right !
>>
>>> 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.
In fact, we could create an error code class containing a ptr_exception. 
I'm not really sure what would be the best. Though, I'd stick to the 
first idea at the moment.
>>
>>> 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?
>
It's an idea that I really like in your implementation, I prefer the 
"make_XXX" non-member function. So I'm totally agree with this idea.
>>> 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 add a "otherwise" method in the proposal.
>>
>> I'll send soon my proposal to the boost mailing-list for any 
>> reviews/comments.
>>
>
>
> Great,
> Vicente

Thanks for all the comments !

Pierre T.