Title
Invalid types in the parameter-declaration-clause of a requires-expression
Status
open
Section
7.5.7.1 [expr.prim.req.general]
Submitter
Barry Revzin

Created on 2022-04-07.00:00:00 last changed 7 months ago

Messages

Date: 2024-03-18.12:50:42

CWG 2023-11-09

The initial example is not the point of the issue, but the very similar following case:

  template <typename T>
  constexpr bool b = requires (T::type x) { x + 1; };

  static_assert(!b<int>);  // de-jure ill-formed, but widely accepted by implementations

Users were vocal they wanted this not to be an error, but just a substitution failure. Reportedly, the original design intent was that this situation is a hard error, though.

Soliciting guidance from EWG how to handle this issue via paper issue 1695.

EWG 2024-03-18

EWG invites a paper to propose a change.

Date: 2023-06-20.19:34:52

Proposed resolution (approved by CWG 2023-06-17):

Change in 7.5.7.1 [expr.prim.req.general] paragraph 5:

The substitution of template arguments into a requires-expression may result in the formation of invalid types or expressions in its parameter-declaration-clause (if any) or its requirements or the violation of the semantic constraints of those requirements. In such cases, ...
Date: 2022-04-07.00:00:00

Consider:

  template <typename T>
  concept C = requires (typename T::type x) {
    x + 1;
  };

  static_assert(!C<int>);

All implementations accept this translation unit. However, the rule in 7.5.7.1 [expr.prim.req.general] paragraph 5 does not cover the parameter-declaration-clause::

The substitution of template arguments into a requires-expression may result in the formation of invalid types or expressions in its requirements or the violation of the semantic constraints of those requirements. In such cases, the requires-expression evaluates to false; it does not cause the program to be ill-formed. The substitution and semantic constraint checking proceeds in lexical order and stops when a condition that determines the result of the requires-expression is encountered. If substitution (if any) and semantic constraint checking succeed, the requires-expression evaluates to true.
History
Date User Action Args
2023-11-09 21:51:56adminsetmessages: + msg7506
2023-11-09 21:51:56adminsetstatus: tentatively ready -> open
2023-06-20 19:34:52adminsetstatus: open -> tentatively ready
2022-04-13 07:01:41adminsetmessages: + msg6793
2022-04-07 00:00:00admincreate