specification of default implementations of sender algorithms in the standard library need to specify when they decay copy values and errors.

[ericniebler]

Issue by ericniebler Wednesday Feb 02, 2022 at 00:51 GMT Originally opened as https://github.com/NVIDIA/stdexec/issues/443

---

See when_all, for example.

[ericniebler]

Comment by lewissbaker Wednesday Feb 02, 2022 at 05:46 GMT

---

Why is this needed?

[ericniebler]

Comment by ericniebler Wednesday Feb 02, 2022 at 05:48 GMT

---

(a) it's observable, (b) it effects whether a sender is no-fail or not (copies/moved can throw)

[ericniebler]

Comment by lewissbaker Wednesday Feb 02, 2022 at 06:01 GMT

---

The when_all sender would presumably conditionally report that it can complete with an exception if decay-copying any of the value-results of any of the input senders is noexcept(false). I don't see why we would need to report that the operation might copy the values as a separate thing.

That a sender copies the value is presumably just part of the specification of that sender/algorithm. Why would a user of that sender need to know whether it copies result values from its child senders?

[ericniebler]

Comment by ericniebler Wednesday Feb 02, 2022 at 20:27 GMT

---

That a sender copies the value is presumably just part of the specification of that sender/algorithm.

I thought the specification was what we were talking about. What I'm saying is that the specification for when_all should say that it necessarily needs to temporarily store values/errors in the operation state. What are you saying?

[ericniebler]

Comment by lewissbaker Thursday Feb 03, 2022 at 06:09 GMT

---

Sorry, for some reason I thought you were suggesting that we add a metafunction/query for a sender (like a completion_signatures query) that would allow a program to query at compile time whether a sender will copy the result of its child.

If its just "specification of default implementations of sender algorithms in the standard library need to specify when they decay copy values and errors..." then that's fine.

The title of the issue to me seemed to imply that this would be a requirement for all sender types (user-defined or otherwise).

[ericniebler]

Comment by ericniebler Saturday Feb 05, 2022 at 17:08 GMT

---

OK, that's reasonable confusion. I've updated the title of the issue.

[lewissbaker]

@ericniebler Has this been addressed to your satisfaction now?

I think the specification of default implementations is reasonably clear when it decay-copies values. However, we don't really specify the requirements on customizations with regards to this behaviour.