search

cplusplus / sender-receiver

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

noexcept requirement in `operation_state` concept seems redundant #21

Open ericniebler opened 10 months ago

ericniebler commented 10 months ago

Issue by bylee20 Friday Feb 03, 2023 at 15:02 GMT _Originally opened as https://github.com/brycelelbach/wg21_p2300_execution/issues/23_

From https://brycelelbach.github.io/wg21_p2300_execution/execution.html#spec-execution.op_state.start

tag_invoke(execution::start, O), if that expression is valid. If the function selected by tag_invoke does not start the work represented by the operation state O, the behavior of calling execution::start(O) is undefined.

Mandates: The tag_invoke expression above is not potentially throwing.

Since execution::start(O) already mandates noexcept here, noexcept-ness should be checked in execution::start(O) by compiler. Then, the requirement of { execution::start(o) } noexcept in operation_state concept will be always satisfied and redundant.

inbal2l commented 3 months ago

@ericniebler @lewissbaker - IIUC (the latest incarnation of) this is discussed as part of https://github.com/cplusplus/sender-receiver/issues/246? (if so, should we unite/close)?

lewissbaker commented 3 months ago

@ericniebler @lewissbaker - IIUC (the latest incarnation of) this is discussed as part of #246? (if so, should we unite/close)?

I don't think that #246 discusses the issue of start() CPO requiring noexcept or not.

It is true that the current wording of the operation_state concept requiring start(o) to be noexcept is somewhat redundant with the start(op) cpo being defined as expression-equivalent to MANDATE-NOTHROW(op.start()) which is ill-formed if op.start() is not noexcept.

I'm not sure if this is something that is harmful, however.

If we wanted to simplify the operation_state concept we could replace the line { start(o) } noexcept; with simply start(o);.

@ericniebler do you know if this was discussed in LWG review?