Title
Compile-time calculation errors in constexpr functions
Status
cd2
Section
Clause [7] [expr]
Submitter
Mike Miller

Created on 2008-06-09.00:00:00 last changed 171 months ago

Messages

Date: 2009-10-15.00:00:00

[Voted into WP at October, 2009 meeting.]

Date: 2009-07-15.00:00:00

Proposed resolution (July, 2009):

This issue is resolved by the resolution of issue 699.

Date: 2008-09-15.00:00:00

Notes from the September, 2008 meeting:

The CWG felt that the concept of “compile-time evaluation” 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 [expr] paragraph 4.

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 1/0 should simply be considered non-constant; any diagnostic would result from the use of the expression in a context requiring a constant expression.

Date: 2020-12-15.00:00:00

Evaluating an expression like 1/0 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 [expr] paragraph 4:

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 [expr.const]), in which case the program is ill-formed.

The formulation “appears where an integral constant expression is required” is intended as an acceptable Standardese circumlocution for “evaluated at compile time,” a concept that is not directly defined by the Standard. It is not clear that this formulation adequately covers constexpr functions.

History
Date User Action Args
2010-03-29 00:00:00adminsetstatus: dr -> cd2
2009-11-08 00:00:00adminsetmessages: + msg2430
2009-11-08 00:00:00adminsetstatus: ready -> dr
2009-08-03 00:00:00adminsetstatus: review -> ready
2009-02-08 00:00:00adminsetmessages: + msg1863
2009-02-08 00:00:00adminsetstatus: drafting -> review
2008-10-05 00:00:00adminsetmessages: + msg1776
2008-10-05 00:00:00adminsetstatus: open -> drafting
2008-06-09 00:00:00admincreate