Should `set_value/error/stopped` CPOs require that member-functions return `void`?

[lewissbaker]

The set_value, set_error and set_stopped CPOs all all currently defined as expression equivalent to a call to the corresponding member function on the receiver, mandating that the call-expression is nothrow.

There is, however, no constraint here to require that the expression is void.

As the specification currently stands, it would be valid to define a receiver with a set_value() method that returned bool, or indeed any other type, and this would still be a valid implementation of a receiver, and the CPO would need to return whatever value the member-function returned.

I wonder whether we'd be better off here requiring the receiver methods to return void so that we reserve future design space for possibly adding semantics to receiver methods that return non-void in future?

[inbal2l]

I don't see downsides for adding such limitation (might save room for defining extended error / status handling in the future?).
@ericniebler @RobertLeahy - WDYT?

[lewissbaker]

Note that the same is currently true of the start CPO.
start(op) is merely defined as expression-equivalent to MANDATE-NOTHROW(op.start()).

It doesn't place any requirements on the return-value.