On 25 May 2015 at 8:27, Rob Stewart wrote:
In case you might want to know why a monadic return transport might be so useful as to be a whole new design idiom for C++ 11, try reading https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a8.DESIGN:Strongl....
Make the examples in that correct WRT shared_ptr. As written, the shared_ptrs will delete file handles rather than close them.
I would imagine destroying an open file handle would close it. Anyway, that really isn't important to the code examples given the topic, it was never mentioned what a handle_type is, I had an afio::async_io_handle in mind but it doesn't matter.
However, future<T> doesn't seem named very "monadic", so I am inclined to turn future<T> into a subclass of a type better named. Options are:
* result<T> * maybe<T>
Or anything else you guys can think of? future<T> is then a very simple subclass of the monadic implementation type, and is simply some type sugar for promise<T> to use to construct a future<T>.
The idea has merit, but I have some concerns. The best practice you've linked states that there are problems with Boost.Threads' expected type, but you only mention compile times specifically. I'd like to better understand why expected cannot be improved for your case. That is, can't expected be specialized to be lighter for cases like yours?
I am one of few here who has seen Expected deployed onto a large code base. The other guy is Lee, who has even more experience than I do. Ours was not a positive experience in a real world large code base use scenario. Expected is a great library. Lovely piece of work. However, it is also enormous. For a simple monadic return transport with traditional unexpected type exception_ptr, it is enormously overkill. It does category theory, huge quantities of constexpr machinery, and a fair chunk of what a variant implementation would need. This is why it is so slow on compile times. When we were using expected, 98% of the time we didn't need any of that. We just wanted a simple Either-Or object which imposed optimal compile and runtime overhead. We just wanted to return some expected type T, or some error, and the monadic operations to work as described without any extra fluff like comparison operations, hashing, container semantics, automatic conversion, variant semantics etc. Also, in terms of it now being 2015, we know WG21 are working on an official variant type - it was the talk of C++ Now. Such a variant is an obvious base class for any expected implementation rather than reinventing the wheel separately. Similarly, the future-ishy parts of expected would make more sense to come from a base future-ishy type which is then composed with a variant type to make an expected type which does all the singing and dancing anyone could desire. That means rewriting expected from scratch sometime later on.
Put another way, I'd rather one type be smart enough to handle common use cases with aplomb than to have many specialized types. I realize that doesn't solve your immediate need, but you have your own namespace so you can just create your own "expected" type until the other is improved. Then, if improvement isn't possible, you can explore another name for your expected type.
Mine isn't an expected implementation. It doesn't even do optional semantics, or even value semantics. It simply provides the simple future API on a fixed variant wrapper type - three quarters of a std::future - nothing more. If you have ever done a lot of make_ready_future() in your code as a quick and dirty Maybe implementation (I know I have), this use is exactly what I am trying to formalise into an enormously more efficient implementation. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/