Example 1.5.1 "then" doesn't seem to work.

[aaron-michaux]

I believe that I've identified two issues with the examples.

• The completion signatures on the _then_sender fail when the function returns void. (error: invalid parameter type 'std::__success_type<void>::type' {aka 'void'}) Some guidance needs to be given on how to handle void return types!
• The _then_receiver relies on base() being a member of the parent class receiver; however, base() isn't part of the specification anywhere. Would it be plausible to have the example static_cast<R&&>(std::move(*this)), or is that somehow wrong. If so, the example needs further exposition on what the example is doing.

[aaron-michaux]

The example also fails if the function must take an input value.

Trying to figure this out from compiler messages and reading the stdexec code is almost impossible.

For example, I cannot copy code from __then.hpp into a new file, and attempt to progressively refactor it in order to understand what all the parts do. (The variable names aren't great... the compiler errors unhelpful.)

I think it's important that we have at least a minimal working example that shows how you'd write a then sender.

In particular, P2300r10 says that "it's a challenge" to write the completion signatures for a sender. No kidding. An example is with 1000 pages of standardize. How do I write the completion signatures?

[aaron-michaux]

For anyone who finds this issue, Maikel Nadolski offers a "naive solution" here. It's for exposition only.

https://godbolt.org/z/5qczb9dhh

[lewissbaker]

Yes, I agree that the examples given for then in P2300R10 section 1.5.1 are not a general implementation of the then algorithm.

Generally, you need to explicitly handle the void/non-void and throwing/non-throwing cases separately to ensure that you instantiation the right overloads of set_value and set_error of the parent receiver. Usually this is done with if constexpr breanches in the implementation.

For handling the computation of the completion-signatures, the stdexec library uses a helper called transform_completion_signatures which provides a kind of declarative syntax for defining what predecessor completion converts into which parent completion signatures.
See https://github.com/NVIDIA/stdexec/blob/999a11e0a82f9e4d0cedb29ed0b0282543b30805/include/stdexec/__detail/__transform_completion_signatures.hpp#L309

And the example usage of this in then: https://github.com/NVIDIA/stdexec/blob/999a11e0a82f9e4d0cedb29ed0b0282543b30805/include/stdexec/__detail/__then.hpp#L38

Having said that, I'm not sure what the actionable item is here.
As P2300 has now been merged into the working draft, it's unlikely we're going to submit a new revision of it. If there is any issue with the wording of what's in the draft then we can raise an LWG issue regarding addressing the wording issue - but I did not get the impression from the description of the issue that this was the case (please correct me if I'm wrong here).