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

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