Does `.via` return `executor_future_t<Executor>`?

[LeeHowes]

No. a) the promise query should not return executor_future_t, nor indeed need it return a real ContinuableFuture b) it could be cheaper defer all of this to the first call to .then, which is why .via on standard_semi_future returns a standard_continuable_future - it just wraps E (and potentially the future from the query) and carries this to the call to then to avoid enqueueing work that won't be used.

[dhollman]

a) the promise query should not return executor_future_t, nor indeed need it return a real ContinuableFuture

But, as specified, the polymorphic executor wrapper needs to be able to wrap whatever is returned in a standard_semi_future, which one could then convert to a standard_continuable_future via a polymorphic executor. Are we sure this process works the whole way through without imposing extra requirements on the second entry in the promise_query_t return value?

Also, I'm not sure the return type of .via is needs to be directly related to the promise query return type.

[LeeHowes]

Yes, I understand your concern with the polymorphic wrapper. No, I'm not 100% sure that this all works fully with the polymorphic executor.

The standard futures can easily type erase other futures in terms of use. .then can forward to a type erased virtualised internal .then.

For both future type erasure and future-token type erasure, allowing the executor to get at the internal object is less clear. Maybe to make that work fully we do need an explicit type erasing wrapper. We need to let the executor define the virtualisation for that, don't we?

[LeeHowes]

This isn't really specific to .via. It's just that if we have some sort of type erased future we may need to type erase. Let's continue discussion on #46.

[LeeHowes]

Discussion continued on #46. Change to fix this particular issue landed. Closing.