search

cplusplus / sender-receiver

Issues list for P2300
Apache License 2.0
20 stars 3 forks source link

Typos/issues Section 8 (General utilities library) #110

Closed ericniebler closed 3 months ago

ericniebler commented 10 months ago

Issue by dietmarkuehl Sunday Jan 16, 2022 at 23:31 GMT Originally opened as https://github.com/NVIDIA/stdexec/issues/398

There are a number of issue with Section 8:

  1. Some declarations in the synopsis have a mismatch between the name used in the template head and the function declaration: Fn vs. Tag.
  2. There are numerous places where the < isn't HTML escaped and the explicit argument list is swallowed when formatted.
  3. Some arguments to std::forward are plain missing.
  4. The expression for the definition of call-result-t is a list of objects rather than a call expression.
  5. There are some casts which are either unnecessary (auto(tag)) or should use std::forward. However, see next item.
  6. The specification in 8.1.2 (tag_invoke) is too verbose. I think it can be expressed in terms of [customization.point.object] (whose reference is missing) and [defns.expression-equivalent] as is done for other customization point objects.

I'm fairly certain about all but the last part. For the last part it may be reasonable to get an opinion from other LWG members. I will add a PR shortly.

ericniebler commented 10 months ago

Comment by ericniebler Sunday Jan 16, 2022 at 23:36 GMT

Thank you! Regarding tag_invoke, I've found that the diagnostics are very bad unless its implementation matches that in P2300. So it borders on overspecialization simply because it's so easy to do it poorly.

ericniebler commented 10 months ago

Comment by dietmarkuehl Sunday Jan 16, 2022 at 23:40 GMT

I have created PR 399 to address the issues mentioned here.

Regarding Eric's comment on recommending an exact implementation: if an exact implementation should be suggested, I think it would best become a Note, e.g., to allow implementations to deviate if they have a better implementation like explicit compiler support. My PR 399 currently doesn't reflect the Note but can update it accordingly if you think that's the way to go.

ericniebler commented 10 months ago

Comment by villevoutilainen Sunday Jan 16, 2022 at 23:43 GMT

Regarding Eric's comment on recommending an exact implementation: if an exact implementation should be suggested, I think it would best become a Note, e.g., to allow implementations to deviate if they have a better implementation like explicit compiler support.

Implementations are always allowed to "deviate" based on the as-if rule.

ericniebler commented 10 months ago

Comment by dietmarkuehl Sunday Jan 16, 2022 at 23:51 GMT

I don't think this section will stay as is. At the very least, a note should be added to motivate why the exact implementation is given. ...and if the exact implementation is given, the casts need to go or it needs to be explicitly mentioned that this formulation is needed as well.

I have already mentioned that I'm not as confident about this particular change than about the others. My objective of this exercise is to streamline the LWG processing of this paper: unless it is of much better quality than nearly all papers we receive we will not manage to get through it for the C++23 time-frame.

lewissbaker commented 3 months ago

I'm pretty sure all of these points have either been addressed or are no longer relevant after 2+ years of LWG review. Closing.