Title
Parameter type determination in a requirement-parameter-list
Status
open
Section
7.5.7.1 [expr.prim.req.general]
Submitter
Daveed Vandevoorde

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

Messages

Date: 2022-03-31.07:31:09

Suggested resolution:

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

A requires-expression may introduce local parameters using a parameter-declaration-clause (9.3.4.6 [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 9.3.4.6 [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
    t;
  };
  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

Consider:

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

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