On 28 Jun 2015 at 17:52, Vinícius dos Santos Oliveira wrote:
monad<T>, result<T> and option<T> are all *synchronous* value transports. Just like Rust's Result and Option.
So, why can result<t> be empty?
The idea was that the synchronous transport editions map semantically onto the asynchronous transport editions. So: Empty <= Unsignalled/Default constructed. Value <= Value. Errored/Excepted <= Errored/Excepted. If you consider a default constructed future, you will see you have to have a default constructed monad be empty. What else could it be? There is also the truth that allowing an empty state makes everything vastly more efficient to implement. For example, I can hard assume that monad<T> will always have a default constructor, and that makes implementing monad<monad<T>> considerably easier. If an exception throws during a move or copy constructor, I can throw the exception out with the monad left empty. In a situation with (de)serialisation, the ability to guarantee default construction no matter what T is is also very valuable. All this turns into a minimum number of assembler instructions output by the compiler, and is why I chose this design.
I mean: result<T, E> is like "give me T or it's an error". There is no empty state. Empty would already be an error state. I'd only understand empty if it's an async operation that didn't finish already.
In case others on boost-dev don't realise, Vinicius here is referring to Rust, not C++. Myself and Vinicius currently work for the same client writing code in Rust, at least until he replaces me in a few week's time! :) Rust's Result<T, E>, and any traditional monad, has no empty state. I would call those "pure monads". My monad is not a pure monad, it is a "dirty" monad with an impure design which I hope/believe is better suited to the typical C++ programmer. For example, monadic parsing is not well suited to my impure design, it does work if you throw an exception to carry the failure to parse state so it "works", but nobody should be doing that in any real world code. I may be wrong in those design tradeoffs and assumptions - just because I've been working on the right design for over a year (I have a presentation I did on these design deliberations February 2014 with many of the same unsolved problems) doesn't mean I am 100% confident in it being the correct balance between all the exigencies. However, the AFIO review is in two weeks, and boost-dev wanted a final AFIO design, so here it is coming best as I can make it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/