On 27 May 2015 at 7:02, Vicente J. Botet Escriba wrote:
So the question is, do we have the proposed interface for expected, or something else? Would be the 'to be named type" a literal type? I would far prefer if Expected were layered with increasing amounts of complexity, so you only pay for what you use.
I also think you need to await the WG21 variant design to become close to completion. It makes no sense to have an Expected not using that variant implementation, you're just duplicating work.
My apologies. No seriously, this are implementation details. Could you describe the interface changes that expected need.
That's a huge question Vicente. And it's very hard to answer in detail, because I don't really know. I don't think variant is an implementation detail. I suspect people will want to explicitly convert from an ordered variant into an expected and vice versa for example. They will also want to "repack" a variant from one ordering of type options into another without actually copying around any data. I can also see a Hana heterogeneous sequence or std::tuple being reduced into variant and/or into an expected. And so on. Until all this ecosystem stuff becomes more final, it is hard to imagine a new expected interface.
Other than that, I found the interface generally good. I only ever needed about 10% of it personally, but it would be nice if the remainder were available by switching it on maybe with an explicit conversion to a more intricate subclass. The more intricate subclass would of course live in a separate header. Pay only for what you use.
Could we define this interface?
If I remember rightly, in your WG21 paper you had a table somewhere where you compared futures to optional to expected with a tick list of features shared and features not shared. I think you need an orthogonal table of: 1. Lightweight monad. 2. Intermediate monad. 3. Featureful monad. ... and another table showing the progression from minimal monad to maximum monad. If you examine https://github.com/ned14/boost.spinlock/blob/master/include/boost/spin lock/future.hpp you should see that monad<>, from which future<> derives, implements simple then(), bind() and map(). future<> only implements then(), but I am planning for it to allow a then(F(monad)) which would allow future to also provide bind() and map(). My idea is you can eventually switch freely between asynchronous monadic programming and synchronous monadic programming using a simple cast, so I am implementing a "two layer" monad where the first is a synchronous monad and the second is an asynchronous monad. But I'm a long way away from any of that right now.
In other words, would the "to be named" type appear on the AFIO interface? Is for this reason that you need to name it? or it is really an implementation detail. This merits clarification.
Right now AFIO's synchronisation object is a struct async_io_op which
contains a shared_future