<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    CWG Issue 695</TITLE>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<STYLE TYPE="text/css">
  INS { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  .INS { text-decoration:none; background-color:#D0FFD0 }
  DEL { text-decoration:line-through; background-color:#FFA0A0 }
  .DEL { text-decoration:line-through; background-color: #FFD0D0 }
  @media (prefers-color-scheme: dark) {
    HTML { background-color:#202020; color:#f0f0f0; }
    A { color:#5bc0ff; }
    A:visited { color:#c6a8ff; }
    A:hover, a:focus { color:#afd7ff; }
    INS { background-color:#033a16; color:#aff5b4; }
    .INS { background-color: #033a16; }
    DEL { background-color:#67060c; color:#ffdcd7; }
    .DEL { background-color:#67060c; }
  }
  SPAN.cmnt { font-family:Times; font-style:italic }
</STYLE>
</HEAD>
<BODY>
<P><EM>This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21
  Core Issues List revision 118b.
  See http://www.open-std.org/jtc1/sc22/wg21/ for the official
  list.</EM></P>
<P>2025-09-28</P>
<HR>
<A NAME="695"></A><H4>695.
  
Compile-time calculation errors in constexpr functions
</H4>
<B>Section: </B>Clause 7&#160; [<A href="https://wg21.link/expr">expr</A>]
 &#160;&#160;&#160;

 <B>Status: </B>CD2
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>9 June, 2008<BR>


<P>[Voted into WP at October, 2009 meeting.]</P>

<P>Evaluating an expression like <TT>1/0</TT> is intended to produce
undefined behavior during the execution of a program but be ill-formed
at compile time.  The wording for this is in Clause 7 [<A href="https://wg21.link/expr#4">expr</A>] paragraph 4:
</P>

<BLOCKQUOTE>

If during the evaluation of an expression, the result is not
mathematically defined or not in the range of representable values for
its type, the behavior is undefined, unless such an expression appears
where an integral constant expression is required (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]), in which case the program is ill-formed.

</BLOCKQUOTE>

<P>The formulation &#8220;appears where an integral constant
expression is required&#8221; is intended as an acceptable
Standardese circumlocution for &#8220;evaluated at compile time,&#8221;
a concept that is not directly defined by the Standard.  It is not
clear that this formulation adequately covers constexpr functions.</P>

<P><B>Notes from the September, 2008 meeting:</B></P>

<P>The CWG felt that the concept of &#8220;compile-time
evaluation&#8221; needs to be defined for use in discussing
constexpr functions.  There is a tension between wanting to
diagnose errors at compile time versus not diagnosing errors
that will not actually occur at runtime.  In this context, a
constexpr function might never be invoked, either in a
constant expression context or at runtime, although the
requirement that the expression in a constexpr function be a
potential constant expression could be interpreted as triggering
the provisions of Clause 7 [<A href="https://wg21.link/expr#4">expr</A>] paragraph 4.</P>

<P>There are also contexts in which it is not known in advance
whether an expression must be constant or not, notably in the
initializer of a const integer variable, where the nature of
the initializer determines whether the variable can be used in
constant expressions or not.  In such a case, it is not clear
whether an erroneous expression should be considered ill-formed
or simply non-constant (and thus subject to runtime undefined
behavior, if it is ever evaluated).  The consensus of the CWG
was that an expression like <TT>1/0</TT> should simply be
considered non-constant; any diagnostic would result from the
use of the expression in a context requiring a constant
expression.</P>

<P><B>Proposed resolution (July, 2009):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="699.html">issue 699</A>.</P>

<BR><BR>
</BODY>
</HTML>
