Re: [boost] Boost.Outcome review - First questions

...

...

...

...

|* |is expected the sum type of T, E and empty? and exception_ptr? expected may only have the state of T or E. The valueless by exception state has been eliminated recently in develop branch. Is this the case also for outcome/result/option? Yes. Great, so result<T> and option<T> wouldn't have no anymore a tri-logic, and outcome<T> would have a tri-logic as it can be T | E | exception_ptr, but never empty.

Formal empty state remains for outcome<T>, result<T>, option<T>. As I've hopefully shown by now in other discussion threads, the formal empty state is very useful, saves a lot of boilerplate. For those not wanting the empty state, there is expected.

I'm not sure, but I believe you maybe will need to double the storage. Have you implemented this already?

I explained before the exact implementation, and where valueless due to exception can still arise. It will be documented soon (this change was implemented during this review).

...

Consider it a populist extension over LEWG Expected. I know you don't like it, and I to be honest think it best used sparingly, but it'll be very popular with many. Popular is not a criteria I will run after.

I am, however, a populist, and that is evident throughout the design of Outcome and especially AFIO v2. I give the people want they want so long as it is not obviously dangerous nor stupid. I appreciate that is not a common design philosophy here, and especially not on WG21. But I think C++ could do with more feeding the masses rather than so much ivory tower design and forcing weird design, build and distribution systems onto end users.

...

...

...

...

* raw types

It is not clear what is the difference between xxx and raw_xxx Logged to https://github.com/ned14/boost.outcome/issues/29 Thanks for creating the issue, but I'm interested in knowing it now during the review. Otherwise I couldn't accept even conditionally the library. When configured with void, value_type, error_type and exception_type are all set to an unusable but usefully named types suitable for compiler warnings and errors. This makes writing metaprogramming much easier as you don't need to deal specially with void and its weird semantics, plus any attempt to use the type causes a very descriptive compiler error.

raw_value_type, raw_error_type and raw_exception_type are the true, original type configured. You are correct that this is a deviation from LEWG Expected which would cause code written for LEWG Expected to fail to compile with Outcome's Expected. I think that safe. If the raw_ are the reason d'être to avoid the void specialization, and this avers to be a useful technique, I believe it merits a full implementation section explaining how this improve the compiler performances, DRY, et all.

I had thought it a very common technique, so common that it not worth explaining here. Am I wrong on this?

I'm not against something I don't understand, in principle, just want to understand why you did the way you did and if it is a good technique adopt it on my proposals.

I suspect it would not be accepted into the STL. Disabling overloads via setting their type to something impossible to match is not something I've ever seen in any STL.

...

...

...

...

* what is the sizeof expected ? It says already at the top of the page. It's max(24, sizeof(R)+8) on 64 bit CPUs. An now that you will ensure the never empty warranties? It's the same sizeof. What are the magic number 24 and 8? I'm sure I can undertand it better if I read the implementation, but I don't I want to read the documentation and understand it.

Is the max of either 24 bytes OR sizeof(T) + 8 So on x64 the bookkeeping for a basic_monad (any implementation) is 8 bytes above the largest possible type stored in the variant storage which is the minimum possible. The presented library has a small space optimisation which can pack storage into one byte in some circumstances, but I'm soon to remove it entirely. It suffers the same problem as vector<bool>, so .value() and .error() suddenly return by value instead of by reference etc.

...

I will document the semantics described above in the tutorial and reference API docs. They are a good balance of never empty warranties with space consumption and runtime overhead. I believe these guarantees are similar to those in your Expected proposal? As in, you don't implement the double buffer solution either. No, I don't need to. There is not need if E concerned function not throw, which I could expect as E is an error.

Cool, then Outcome's Expected is now conforming to your proposal in this area.

...

...

This is what I don't like of your library. In order to have a common implementation you sacrifice the concrete interfaces. The common implementation is the heart and soul of Outcome, and is precisely its "value add" over most other Either monad or Expected implementations. A common implementation allows seamless interoperation between implementations. It lets you write code using expected with outcome<T>, result<T> and option<T> all using the exact same framework. End users can extend the family with any arbitrary custom error transport of their choosing for some bespoke use case.

Your solution is intrusive IMHO.

Yes, that is fair.

How boost::experimental::expected will interact with std::experimental::expected or std::optional<T>, or something else that behaves like a monad error?

Did you mean boost::outcome::experimental::expected? The answer is that we currently don't. The seamless interop applies to within Outcome's island of types only. However it is very straightforward to write converting constructors to construct the std::* editions into Outcome editions. Getting them back out is on the end user, though I could be persuaded to write an explicit conversion operator for the std::** editions. This sort of relationship is exactly the one you previously said is how you would have implemented each of outcome<T>, result<T>, option<T> and expected in Outcome, so each has a totally standalone and unrelated implementation, and each provides custom conversion mechanics into the others. That would be the traditional way of implementing this. I chose not to follow that design in this particular case.

...

...

Niall, please, don't wait until the review is finished to tell us how the issues will be fixed. You could do it on each issue and come back in this ML. I try my best to do so. But a lot of time, how the issues will be fixed is very obvious: I copy and paste documentation from one location to another for example, or I repair an incorrect constructor so it is correct and so on. It's not rocket science to deduce how most issues will be fixed.

It could be obvious for you, but we need to review those possible changes before accepting the library.

I will try to do better. I was particularly lacking in time to do this review until yesterday because I had my final maths coursework to complete and submit. That went in yesterday. I should have a lot more free time not at 1am in the morning from now on. That should make for better quality replies here, I am not at my best so late at night.

Niall, I'm not against not for you library. We're just reviewing it now. For me the goal is to improve it, and if we can at the same time improve the std expected proposal this will be very valuable to the C++ community.

I would be very glad if this process helps the Expected proposal. Expected is a great proposal, it needs into the C++ standard. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/