[2025-06 CWG Motion 1] Core Language Working Group "ready" Issues for the June, 2025 meeting

source/declarations.tex

@@ -6192,9 +6192,10 @@
 ``\cvqual{cv1} \tcode{T1}'' by
 user-defined conversion\iref{dcl.init,over.match.copy,over.match.conv};
 the program is ill-formed if the corresponding non-reference
-copy-initialization would be ill-formed. The result of the call to the
+copy-initialization would be ill-formed. The result $E$ of the call to the
 conversion function, as described for the non-reference
-copy-initialization, is then used to direct-initialize the reference.
+copy-initialization, is then used to direct-initialize the reference
+using the form \tcode{($E$)}.
 For this direct-initialization, user-defined conversions are not considered.
 \item
 Otherwise,

source/expressions.tex

@@ -4384,8 +4384,7 @@
 If \tcode{T} is an lvalue reference type
 or an rvalue reference to function type, the result is an lvalue;
 if \tcode{T} is an rvalue reference to object type, the result is an xvalue;
-otherwise, the result is a prvalue. The \keyword{static_cast} operator shall not cast
-away constness\iref{expr.const.cast}.
+otherwise, the result is a prvalue.
 
 \pnum
 \indextext{cast!static!reference}%
@@ -4474,36 +4473,11 @@
 \end{note}
 
 \pnum
-Otherwise,
-the inverse of a standard conversion sequence\iref{conv} not containing an
-lvalue-to-rvalue\iref{conv.lval},
-array-to-pointer\iref{conv.array},
-function-to-pointer\iref{conv.func},
-null pointer\iref{conv.ptr}, null member pointer\iref{conv.mem},
-boolean\iref{conv.bool}, or
-function pointer\iref{conv.fctptr}
-conversion, can be performed explicitly using \keyword{static_cast}. A
-program is ill-formed if it uses \keyword{static_cast} to perform the
-inverse of an ill-formed standard conversion sequence.
-\begin{example}
-\begin{codeblock}
-struct B { };
-struct D : private B { };
-void f() {
-  static_cast<D*>((B*)0);               // error: \tcode{B} is a private base of \tcode{D}
-  static_cast<int B::*>((int D::*)0);   // error: \tcode{B} is a private base of \tcode{D}
-}
-\end{codeblock}
-\end{example}
-
-\pnum
-The lvalue-to-rvalue\iref{conv.lval},
+Otherwise, the lvalue-to-rvalue\iref{conv.lval},
 array-to-pointer\iref{conv.array}, and
 function-to-pointer\iref{conv.func} conversions are applied to the
-operand. Such a \keyword{static_cast} is subject to the restriction that
-the explicit conversion does not cast away
-constness\iref{expr.const.cast}, and the following additional rules
-for specific cases:
+operand, and the conversions that can be performed using \keyword{static_cast} are listed below.
+No other conversion can be performed using \keyword{static_cast}.
 
 \pnum
 A value of a scoped enumeration type\iref{dcl.enum}
@@ -4619,9 +4593,6 @@
 \end{codeblock}
 \end{example}
 
-\pnum
-No other conversion can be performed using \keyword{static_cast}.
-
 \rSec3[expr.reinterpret.cast]{Reinterpret cast}
 
 \pnum

source/intro.tex

@@ -71,8 +71,8 @@
 Language Specification},
 Standard Ecma-262, third edition, 1999.
 \item
-The Unicode Consortium. \doccite{The Unicode Standard}.
-Available from: \url{https://www.unicode.org/versions/latest/}
+The Unicode Consortium. \doccite{The Unicode Standard}, Version 15.1.
+Available from: \url{https://www.unicode.org/versions/Unicode15.1.0/}
 \end{itemize}
 \indextext{references!normative|)}
 
@@ -874,6 +874,11 @@
 \ref{implimits} lists some quantities that can be subject to limitations and
 a potential minimum supported value for each quantity.
 
+\pnum
+A conforming implementation may use an implementation-defined version
+of the Unicode Standard that is a later version than the one
+referenced in \ref{intro.refs}.
+
 \pnum
 A conforming implementation may have extensions (including
 additional library functions), provided they do not alter the

source/lex.tex

@@ -588,16 +588,23 @@
 the next preprocessing token is the longest sequence of
 characters that could constitute a preprocessing token, even if that
 would cause further lexical analysis to fail,
-except that a \grammarterm{header-name}\iref{lex.header} is only formed
+except that
 \begin{itemize}
 \item
-after the \tcode{include} or \tcode{import} preprocessing token in a
-\tcode{\#include}\iref{cpp.include} or
-\tcode{import}\iref{cpp.import} directive, or
-
+a \grammarterm{header-name}\iref{lex.header} is only formed
+\begin{itemize}
 \item
-within a \grammarterm{has-include-expression}.
-
+immediately after the \tcode{include}, \tcode{embed}, or \tcode{import} preprocessing token in a
+\tcode{\#include}\iref{cpp.include}, \tcode{\#embed}\iref{cpp.embed}, or
+\tcode{import}\iref{cpp.import} directive, respectively, or
+\item
+immediately after a preprocessing token sequence of \xname{has_include}
+or \xname{has_embed} immediately followed by \tcode{(}
+in a \tcode{\#if}, \tcode{\#elif}, or \tcode{\#embed} directive\iref{cpp.cond,cpp.embed} and
+\end{itemize}
+\item
+a \grammarterm{string-literal} token is never formed
+when a \grammarterm{header-name} token can be formed.
 \end{itemize}
 \end{itemize}
 

source/overloading.tex

@@ -2126,24 +2126,13 @@
 defined for the purposes of \ref{over}; the actual initialization is
 defined in terms of constructors and is not a conversion.
 \end{note}
-Any difference in top-level cv-qualification is
-subsumed by the initialization itself and does not constitute a conversion.
-\begin{example}
-A parameter of type
-\tcode{A}
-can be initialized from an argument of type
-\tcode{const A}.
-The implicit conversion sequence for that case is the identity sequence; it
-contains no ``conversion'' from
-\tcode{const A}
-to
-\tcode{A}.
-\end{example}
 
 \pnum
-When the parameter has a class type and the argument expression has the
-same type, the implicit conversion sequence is an identity conversion.
+When the cv-unqualified version of the type of the argument expression
+is the same as the parameter type,
+the implicit conversion sequence is an identity conversion.
 When the parameter has a class type and the argument expression has a
+(possibly cv-qualified)
 derived class type, the implicit conversion sequence is a
 derived-to-base
 \indextext{conversion!derived-to-base}%
@@ -2153,6 +2142,14 @@
 There is no such standard conversion; this derived-to-base conversion exists
 only in the description of implicit conversion sequences.
 \end{note}
+\begin{example}
+An implicit conversion sequence from an argument of type \tcode{const A}
+to a parameter of type \tcode{A} can be formed,
+even if overload resolution for copy-initialization of \tcode{A}
+from the argument would not find a viable function\iref{over.match.ctor,over.match.viable}.
+The implicit conversion sequence for that case is the identity sequence; it
+contains no ``conversion'' from \tcode{const A} to \tcode{A}.
+\end{example}
 
 \pnum
 When the parameter is the implicit object parameter of a static member function,