P1084R2 Today’s return-type-requirements Are Insufficient

[expr.prim.req.compound] Renamed C5 to C3 in remaining example.

Author: Dawn Perchik

source/expressions.tex

@@ -2600,7 +2600,7 @@
 \begin{bnf}
 \nontermdef{return-type-requirement}\br
     trailing-return-type\br
-    \terminal{->} \opt{cv-qualifier-seq} constrained-parameter \opt{cv-qualifier-seq} \opt{abstract-declarator}
+    qualified-concept-name
 \end{bnf}
 
 \pnum
@@ -2610,45 +2610,51 @@
 semantic properties proceed in the following order:
 
 \begin{itemize}
-\item Substitution of template arguments (if any)
-into the \grammarterm{expression} is performed.
-
-\item If the \tcode{noexcept} specifier is present,
-\tcode{E} shall not be a potentially-throwing expression\iref{except.spec}.
-
-\item If the \grammarterm{return-type-requirement} is present, then:
-
-\begin{itemize}
-\item Substitution of template arguments (if any)
-into the \grammarterm{return-type-requirement} is performed.
-
-\item If the \grammarterm{return-type-requirement} is a
-\grammarterm{trailing-return-type},
-%%% FIXME: is -> shall be
-\tcode{E} is implicitly convertible to
-the type named by the \grammarterm{trailing-return-type}.
-If conversion fails, the enclosing \grammarterm{requires-expression}
-is \tcode{false}.
-
-\item If the \grammarterm{return-type-requirement}
-starts with a \grammarterm{constrained-parameter}\iref{temp.param},
-the \grammarterm{expression} is deduced against
-an invented function template \tcode{F}
-using the rules in \ref{temp.deduct.call}.
-\tcode{F} is a \tcode{void} function template
-with a single type template parameter \tcode{T}
-declared with the \grammarterm{constrained-parameter}.
-A \grammarterm{cv-qualifier-seq} \cv{} is formed
-as the union of \tcode{const} and \tcode{volatile} specifiers
-around the \grammarterm{constrained-parameter}.
-\tcode{F} has a single parameter
-whose \grammarterm{type-specifier} is \cv{}~\tcode{T}
-followed by the \grammarterm{abstract-declarator}.
-%%% FIXME: Remove this; if deduction fails, the construct should
-%%% be ill-formed.
-If deduction fails,
-the enclosing \grammarterm{requires-expression} is \tcode{false}.
-\end{itemize}
+\item
+  Substitution of template arguments (if any)
+  into the \grammarterm{expression} is performed.
+\item
+  If the \tcode{noexcept} specifier is present,
+  \tcode{E} shall not be a potentially-throwing expression\iref{except.spec}.
+\item
+  If the \grammarterm{return-type-requirement} is present, then:
+  \begin{itemize}
+  \item
+    Substitution of template arguments (if any)
+    into the \grammarterm{return-type-requirement} is performed.
+  \item
+    If the \grammarterm{return-type-requirement} is a
+    \grammarterm{trailing-return-type}\iref{dcl.decl},
+    %%% FIXME: is -> shall be
+    \tcode{E} is implicitly convertible to
+    the type named by the \grammarterm{trailing-return-type}.
+    If conversion fails, the enclosing \grammarterm{requires-expression}
+    is \tcode{false}.
+  \item
+    If the \grammarterm{return-type-requirement} is
+    a \grammarterm{qualified-concept-name}\iref{temp.param} of the form
+    \opt{\grammarterm{nested-name-specifier}} \grammarterm{concept-name},
+    the concept it denotes shall be satisfied with
+    \tcode{decltype((E))} as its sole argument.
+    If the \grammarterm{return-type-requirement} is
+    a \grammarterm{qualified-concept-name} of the form
+    \opt{\grammarterm{nested-name-specifier}} \grammarterm{concept-name}
+    \tcode{<} \opt{\grammarterm{template-argument-list}} \tcode{>},
+    the concept it denotes shall be satisfied with
+    \tcode{decltype((E))} as its first argument and with
+    the elements, in the order listed, of
+    the \grammarterm{template-argument-list}
+    comprising the concept’s subsequent arguments.
+    \begin{note}
+    Thus, constraints of the form
+    \tcode{\{ E \} -> Concept;} or of the form
+    \tcode{\{ E \} -> Concept<>;} are equivalent to
+    \tcode{E; requires Concept<decltype((E))>;}
+    while a constraint of the form
+    \tcode{\{ E \} -> Concept<A$_1$, A$_2$, . . . , A$_n$>;} is equivalent to
+    \tcode{E; requires Concept<decltype((E)), A$_1$, A$_2$, ..., A$_n$>;}.
+    \end{note}
+  \end{itemize}
 \end{itemize}
 
 \begin{example}
@@ -2675,32 +2681,13 @@
 \tcode{typename T::inner}.
 
 \begin{codeblock}
-template<typename T, typename U> concept C3 = requires (T t, U u) {
-  t == u;
-};
-template<typename T> concept C4 = requires(T x) {
-  {*x} -> C3<int> const&;
-};
-\end{codeblock}
-The \grammarterm{compound-requirement}
-requires that \tcode{*x} be deduced
-as an argument for the invented function:
-\begin{codeblock}
-template<C3<int> X> void f(X const&);
-\end{codeblock}
-In this case, deduction only succeeds if
-an expression of the type deduced for \tcode{X}
-can be compared to an \tcode{int}
-with the \tcode{==} operator.
-
-\begin{codeblock}
-template<typename T> concept C5 =
+template<typename T> concept C3 =
   requires(T x) {
     {g(x)} noexcept;
   };
 \end{codeblock}
 
-The \grammarterm{compound-requirement} in \tcode{C5}
+The \grammarterm{compound-requirement} in \tcode{C3}
 requires that \tcode{g(x)} is a valid expression and
 that \tcode{g(x)} is non-throwing.
 \end{example}