This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 114b. See for the official list.


2560. Parameter type determination in a requirement-parameter-list

Section:  [expr.prim.req.general]     Status: DR     Submitter: Daveed Vandevoorde     Date: 2020-01-21     Liaison: EWG

[Accepted as a DR at the March, 2024 meeting.]


  template<typename T>
    requires requires (T p[10]) { (decltype(p))nullptr; }
  int v = 42;
  auto r = v<int>; // well-formed? 

This example is only well-formed if the type of the parameter p is adjusted to T*, but the provisions in [dcl.fct] paragraph 5 cover function parameters only.

One option is to specify application of the same adjustments as for function parameters. Another option is to specify rules that arguably are more useful in a requires-expression.

Proposed resolution (approved by CWG 2023-11-07):

Change in [expr.prim.req.general] paragraph 3 as follows:

A requires-expression may introduce local parameters using a parameter-declaration-clause ( [dcl.fct]). A local parameter of a requires-expression shall not have a default argument. The type of such a parameter is determined as specified for a function parameter in [dcl.fct]. These parameters have no linkage, storage, or lifetime; they are only used as notation for the purpose of defining requirements. The parameter-declaration-clause of a requirement-parameter-list shall not terminate with an ellipsis.
[Example 2:
  template<typename T>
  concept C = requires(T t, ...) {  // error: terminates with an ellipsis
  template<typename T>
  concept C2 = requires(T p[2]) {
    (decltype(p))nullptr;           // OK, p has type "pointer to T"
end example]

CWG 2023-06-17

There are arguments in favor of both options. Forwarded to EWG with paper issue 1582.

EWG 2023-11-07

Accept the proposed resolution and forward to CWG for inclusion in C++26.