Boost logo

Boost :

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 :
>>>>> Finally, feel free to explore the documentation I wrote
>>>>> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at