`future<void>`

[brycelelbach]

We've never really discussed void. One of the most annoying things about writing futures today is dealing with void. E.g. you end up doing:

template <typename T>
struct continuatble_future;

template <typename T>
struct continuable_future
{
   template <typename Executor>
   auto via(Executor&& exec);

   template <typename Continuation>
   continuable_future</*...*/> then(Continuation&& c);
};

template <t>
struct continuable_future<void>
{
   template <typename Executor>
   auto via(Executor&& exec);

   template <typename Continuation>
   continuable_future</*...*/> then(Continuation&& c);
};

The executors proposal does special case void as well - so perhaps the burden has moved to executor authors instead of future authors (although often they are the same person).

I'd like to discuss alternatives to void. void isn't regular, so it complicates everything - from the wording to the implementation.

[RedBeard0531]

We are still on C++14 for a few more weeks so I don't know for sure, but I expect that the majority of the pain for future<void> will be solved by if constexpr(is_void_v(T)) in C++17. That could be due to a peculiarity of our implementation which holds a future<FakeVoid>, and delegates much of that weirdness to a gross set of helpers to call user callbacks.

Does anyone have much experience writing future<void> in a c++17 codebase? Is the grass any greener?

[LeeHowes]

@yfeldblum any opinion on this? Currently we do not use void here.

[yfeldblum]

It depends on whether we need futures to represent results of computations, which can be void in C++, rather than representing values, which cannot be void. There is a tradeoff here. Without void, implementations are simpler, but futures cannot faithfully represent results of computations.

It seems like it would be useful for futures and coroutines to play well together, and coroutines may return void. Coroutine promises and futures must support that.

In terms of additional complexity, I am more concerned about forcing it onto authors of generic combinators and combinator libraries (e.g., on_value) than I am about forcing it onto authors of future implementations. Perhaps if constexpr can lessen that concern, but it will not eliminate it - they will still have to remember to do the conditional each time.

So I am mixed.

[RedBeard0531]

Could it be conditionally supported along the lines of "If the Future implementations supports Future, the signatures and behavior shall be ..."?

On particular case where we found future<void> to come up is as the only correct return type for Socket::sendMessage(Message) where message knows its size and sendMessage either sends the whole message or fails with an error. This doesn't feel like a "computation" in all but the loosest sense.

[yfeldblum]

(As I was using the term, it's an effectful/side-effecting computation, as v.s. a pure/side-effect-free computation.)

[griwes]

You can implement support for void by annoyingly wrapping every use of T into something like std::conditional<std::is_void_v<T>, fakevoid, T> and then doing silly things in user-facing places to actually support the different signatures. I think this is the best strategy, and one reason for that is it's going to hurt less than a specialization when (if?) regular void lands.

I'm 100% okay with people having futures that don't (currently) support void. As @yfeldblum mentioned - if your computation is free of side effects, and you know that your future type is only for those computations, then going out of your way to support void would be nonsensical. So I'd say that we don't require futures to always support void, and we just add weasel wording for the concrete types to say what we mean just like #105 does.

[brycelelbach]

In an earlier version of HPX, we had a struct unused_type { }; that we used to ease implementation; in prototypes that @griwes and I have mocked up, I've used a similar rvoid struct (e.g. regular void).

[brycelelbach]

Could it be conditionally supported along the lines of "If the Future implementations supports Future, the signatures and behavior shall be ..."?

Yes, that would be one solution.

I think @yfeldblum's point is a strong one - this won't just be a burden for future authors, but also for those writing generic code that consumes futures.

That said, it will also be a burden to users if void isn't returned, as they'll have to create some helper empty struct to return from their continuations.

[brycelelbach]

We should discuss this on a call.

[yfeldblum]

Note that we already have std::monostate as a unit type.

[griwes]

I was very careful not to use a publicly-usable type, becuase users will end up with a future<std::monostate>, for whatever reason.

[RedBeard0531]

FWIW, I just conducted an informal poll of developers around me. Nobody wants to just a futures lib that requires explicit use of std::monostate or anything like that.

return get_an_int().then([](int i) {
    use(i);
    return std::monostate();
}).then([](std::monostate) {
    doNextThing();
    return std::monostate();
});

seems much grosser than:

return get_an_int().then([](int i) {
    use(i);
}).then([] {
    return doNextThing();
});

Or in that simple case, removing the wrapping lambdas to just call the existing functions (if they exist).

If a Future implementer wants to use monostate as in internal implementation detail, that's fine. But it seems bad to let that detail leak out to the public API.