Proposed resolution:

This wording is relative to N4964.

1. Modify [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.

[ 2024-03-11; Reflector poll ]

Set priority to 3 after reflector poll.

LWG 2487 doesn't seem to intend to forbid volatile support as a conforming extension.

P1065R2 made it ill-formed for std::bind but didn't make the same change to the definition of perfect forwarding call wrapper. So given an `as_volatile` function that works like `std::as_const`, as_volatile(std::bind(&T::fn))(t) is ill-formed but as_volatile(std::mem_fn(&T::fn))(t) is undefined. Supporting it as a conforming extension is fine, but making it UB is not. Maybe "conditionally supported" instead?

[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.