Parameter type determination in a requirement-parameter-list
Section [expr.prim.req.general]
Daveed Vandevoorde

Created on 2020-01-21.00:00:00 last changed 1 month ago


Date: 2022-03-31.07:31:09

Suggested resolution:

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
  concept C2 = requires(T p[2]) {
    (decltype(p))nullptr;           // OK, p has type "pointer to T"
end example]
Date: 2020-01-21.00:00:00


  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.

Date User Action Args
2022-03-31 07:31:09adminsetmessages: + msg6784
2020-01-21 00:00:00admincreate