4007. Mystic prohibition of calling a volatile-qualified perfect forwarding call wrapper

Section: 22.10.4 [func.require] Status: New Submitter: Jiang An Opened: 2023-11-05 Last modified: 2023-11-05 11:06:54 UTC

Priority: Not Prioritized

View all other issues in [func.require].

View all issues with New status.

Discussion:

22.10.4 [func.require]/4 says:

[…] This forwarding step delivers a state entity of type T as cv T& when the call is performed on an lvalue of the call wrapper type and as cv T&& otherwise, where cv represents the cv-qualifiers of the call wrapper and where cv shall be neither volatile nor const volatile.

The "shall" seemingly indicates a requirement for user codes that calling a volatile perfect forwarding call wrapper is undefined behavior. Such requirement seems to be combined with requirements for implementations in an unusual way.

Moreover, it is unclear whether UB is intended here. Perhaps we only want calling such a volatile wrapper to be conditionally-supported. E.g. when the operator() happens to be implementable as a static member function, calling a volatile wrapper can be naturally supported and have expected behavior.

Proposed resolution:

This wording is relative to N4964.

  1. Modify 22.10.4 [func.require] as indicated:

    4 A perfect forwarding call wrapper is an argument forwarding call wrapper that forwards its state entities to the underlying call expression. This forwarding step delivers a state entity of type T as cv T& when the call is performed on an lvalue of the call wrapper type and as cv T&& otherwise, where cv represents the cv-qualifiers of the call wrapper and where cv shall be neither volatile nor const volatile, except that if cv is either volatile or const volatile, it is unspecified whether the call is well-formed.