facebookexperimental / facebookexperimental/libunifex

Add support for senders whose result-type is dependent on the receiver type

Open
#16 0 comments 0 reactions 1 assignee Claimed by @lewissbaker View on GitHub
Dominant language
C++
Stars
1.7k
Forks
210
PR merge metrics
No merged PRs in 30d

Description

One of the patterns supported by senders is to allow contextual information from the calling site (receiver) to be injected into the callee (sender) using the receiver passed to the `connect()` operation.

For example, the `get_stop_token()` CPO can be called by a sender to query the stop-token contextual information from the receiver passed to `connect()`. Similarly, the `get_allocator(context)` CPO allows a sender to query the current allocator.

There will be cases where the result-type of a sender is dependent on the contextual information provided through the receiver. For example, a reduce algorithm that cumulates elements from a stream into a `std::vector` might produce a `std::vector` that uses the allocator obtained from calling `get_allocator(context)`.

This means that the `sender::value_types` and `sender::error_types` type-aliases may not yet have enough information to determine the types of the values they will send. However, once we have access to a receiver (ie. in the `connect()` function or the operation-state object returned from it) we can correctly calculate the value_types/error_types that will be sent.

Thus, to support using these types of senders with algorithms that need to know what types of values/errors will be sent we should probably allow/require defining the value_types/error_types on the operation-state type instead-of/as-well-as on the sender type.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.