Support allocators in the standard types that we provide

[brycelelbach]

Note that this is just for std::execution::semi_future<T>, etc.

[brycelelbach]

@LeeHowes, please review, comment, discuss with @griwes and remove the discussion label when you have consensus.

@griwes, can you implement this?

[LeeHowes]

I think doing so makes sense. They will presumably need to allocate shared state so giving control of how that happens is a good idea.

Do we want to type erase the allocator?

[griwes]

I don't think we want to type erase the allocator. We can provide pmr aliases if someone deems that necessary. (Or people can just use polymorphic_allocator.)

I'll sit down to write the wording once I've given my talk.

[LeeHowes]

I think having an allocator template param on those types is fine.

When we construct off of an ContinuableFuture/SemiFuture concept implementation (or execution::promise off of a Promise) we should be clear that we don't assume that that concept also has an allocator. This would be for the shared state needed to allocate storage for that wrapping.

[dhollman]

Shouldn't this basically default to execution::query(fut.get_executor(), execution::allocator)? In other words, it's not really the Future allocating the shared state, but the executor, and that already has an allocator customization point.

I also think we should be clear that the concepts should not be required to support allocators (I know this isn't what you're suggesting here, but it's an important distinction to make). This also means that if the standard types we provide are to act as type-erasers, the type-erasing constructors, etc., should not be required to interoperate with allocators.

[griwes]

Concepts should not require supporting allocators, yes.

For the std::execution::semi_future and whatnot, when it's returned by the executor - sure, but sometimes you'll get it by other means, hence why std::execution::semi_future should support allocators for the type-erased case (and when returned from the default query, you could just propagate the allocator from the executor into the future) - because then it's the future itself that does the allocation of the shared state that does the erasure.

[dhollman]

sure, but sometimes you'll get it by other means

I'm still not convinced of the necessity of "getting it by other means," especially if the goal of this proposal is still to provide something for executors to interoperate with.

That minor soapbox aside, though, can't you just defer any allocation until it's bound to an executor? What allocation would need to be done for a semi_future that has never been bound to any executor? (If it comes from continuable_future::semi(), allocation will have been done in the presence of an executor there also).

[griwes]

"Other means" means constructing a type-erased wrapper. And no, you can't defer until being bound, because once you exit the templated constructor semi_future::semi_future(SemiFuture &&), you know longer know what the type was. You need to somehow save a typed shared state that refers to a type known only inside the constructor.

[dhollman]

Ah, good point. I was not thinking about the allocation of the type-erased wrapper itself.

[LeeHowes]

So I think we want an allocator parameter for:

• executorless make_promise_contract
• semi-future constructor from SemiFuture

via, then, make_promise_contract with executor would all use the target executor's allocator of they allocate.

and an allocator type in the promise/semi_future/continuable_future template parameter list.