On 26 May 2015 at 19:56, Vicente J. Botet Escriba wrote:
Names suggested so far are maybe, result, holder, value. Neither result, holder nor value conveys the fact that the value can not be there. maybe<T> has already the connotation T or nothing as optional. There is no place for error_code and exception_ptr. If the type is not related to thread synchronization, here they are some alternative names: probably_value<T>, probable<T>? probable<T> vs result<T> vs maybe<T>. Hmm, I'll have to think about it.
result<int> v(5); assert(v.get()==5); v.set_value(6); assert(v.get()==6); v.set_exception(foo()); v.get(); // throws foo v.set_error(error_code); v.get(); // throws system_error(error_code) This is quite close to expected, isn't it? I lean on expected's design yes. I like the expected design. No point inventing a new API after all, we know yours works.
The compiler treats a default initialised monad identically to a void return i.e. zero overhead. Ah, then the to be named type has the additional ready state. This is closer to a valid future with the addition of the promise (setting) interface. Exactly right. No surprises.
I have no problem. There are not proper and dirty monads. Purist will give you the good name. I see several nested monads. IIUC, the type doesn't has the invalid state, isn't it? It has valid() on the future<T>. But not on the monad. So I suppose not. Then you to be named type is between expected and future. if it can be used asynchronously it could be seen as a valid_future<T>. Then a future coul dbe seen as a specialization of
Le 27/05/15 01:36, Niall Douglas a écrit : optional<valid_future<T>>. Otherwise, if it is synchronous, it could be seen as an specialization of optional<expected<T>>. Does your "to be named" type provide wait(), then() , ....?
expected integration is very far away for me. I'm even a fair distance from continuations, because getting a std::vector to constexpr collapse is tricky, and you need a std::vector<std::function> to hold the continuations. Why do you need to store store a vector of continuations. You have just one. What am I missing? It makes my implementation a lot easier if I can add an unknown number of continuations (non-consuming, therefore they are really C type callbacks) to some future. Remember I am optionally supporting Boost.Fiber later on, and I need an extensible and generic way of firing off coroutines on future signal with minimal #ifdef code branches all over the place.
Under the Concurrency TS you'd implement this by creating a callable struct which contains the vector of more continuations, so as an example:
struct many_continuations { std::vector<std::function<void(const std::future &)>> nonconsuming; std::function<void(std::future)> consuming; void operator()(std::future v) { for(auto &c : nonconsuming) c(v); } consuming(v); };
... and now do future.then(many_continuations());
I'm simply building that same functionality straight into my future instead of having external code bolt it on.
This is a functionality that shared_future<T> accepts already. Note that shared here is related to the underlying T value. As you said, don't pay for what you don't use. The many_continualions functor is only one way to achieve that. If you (the user) are looking for performances you can have a more intrusive solution. Does your "to be named" type provide this kind of consuming/not-consuming continuations? It is difficult to nane something we don't know which interface and semantics it has.
My main goal is getting AFIO past peer review for now.
As others I'm waiting for a written proposal. But I think this is not on your plans. Nope. My priority is AFIO. I have about two months to deliver it. We'll go from there after.
If we are discussing here of internal implementation details of AFIO, I would suggest you spent this time to improve the interface and the documentation and documenting the performances. You will have all the time to improve the implementation and its performances before going to a release. If we are discussing here of another possible boost classes (even if only part of AFIO), then it is different. 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. Best, Vicente