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

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