N3071 questions exact representation in constexpr initializers
A UK committee-draft comment asks what preserving a value means across floating-point types. Complex values, signed zero, and NaNs expose ambiguities beyond ordinary rounding.
Requiring a compile-time initializer to preserve its value sounds simpler than defining it. Joseph Myers's N3071 examines cases where C's existing conversion rules do not answer whether a value has changed. The WG14 document log lists the paper on December 23 as a UK comment on the C2x committee draft.
The draft requires the values used to initialize constexpr objects to be exactly representable in the corresponding target type. Myers points out that conversion rules normally need to specify a result. They do not always need to define whether values in different types are the same. A new constraint based on exact preservation therefore asks those rules to answer an additional question.
C's small language is part of its appeal to me, but floating-point semantics illustrate how much precision its specification still needs. A restriction that a compiler must diagnose needs a clearer definition than an informal expectation that a number survives conversion. N3071 is useful because it gives concrete cases without pretending the answers are already settled.
A real value and a complex value
Myers assumes Annex F applies to binary floating-point arithmetic, with float and double using binary32 and binary64. Under those assumptions, he first asks about conversion from a real type to a complex type. The paper gives this declaration as a question for the committee.
constexpr _Complex double x1 = 1.0;
The issue is not whether the ordinary conversion has a defined result. It is whether a real value and a complex value with a zero imaginary component count as the same value for the new initializer constraint. The declaration illustrates an unresolved draft interpretation, not a portable example whose acceptance this paper guarantees.
The reverse direction exposes the same question. An initializer can have complex type and a real component exactly representable in the destination's real type. If the imaginary part is zero, should converting to a real object count as preserving the value? The ordinary conversion semantics do not by themselves settle how the constexpr constraint should classify it.
Signed zero makes that question more specific. N3071 asks whether a negative zero imaginary component should receive the same treatment as the zero introduced by real-to-complex conversion. A description based only on ordinary numerical equality risks ignoring information that the floating-point model can distinguish.
NaNs do not fit a range argument
The existing conversion language discusses exact representation alongside being within or outside a type's range. Myers observes that NaNs are unordered, so that classification does not cover them in the same way. A quiet NaN also raises questions about its payload and the implementation's conversion rules between different formats.
The paper asks whether quiet NaNs are exactly representable across standard floating types in all cases or only in some cases. That is a question about what information the initializer constraint preserves. Accepting that the destination can hold a NaN does not determine whether every distinction in the source NaN must survive.
Signaling NaNs add an operational concern. Myers notes an argument against accepting conversions between different formats because conversion would produce a quiet NaN. He also asks about types that share a format, where the answer may depend on whether the operation is a format conversion or a copy.
This is why the paper does not simply recommend accepting every conversion whose result has the same broad category. A constraint based on unchanged value needs a policy for distinctions within that category. The compiler must then apply that policy consistently when deciding whether a declaration violates the constraint.
Decimal types preserve additional information
The decimal cases ask about quantum exponents. N3071 distinguishes the real number represented from the additional floating-point representation information. A number may be representable in both binary and decimal types while the forms do not carry identical exponent information.
Myers asks about both directions of conversion, including integers, infinities, and quiet NaNs. He also asks whether a finite decimal value's quantum exponent must match the result of converting in the reverse direction. These subcases prevent a general claim about numeric equality from silently determining all the rules.
Even conversion between decimal types creates a question. The real number can remain representable while its quantum exponent is not representable in the target type. The paper points to an example in the draft whose comment says such initialization is invalid, then questions whether the normative text actually establishes that result.
I prefer this form of standards criticism because the requested correction is specific. The committee needs normative rules that support a diagnostic, including cases the explanatory examples currently assume. A comment in an example is useful guidance, but it cannot replace the rule that makes the declaration valid or invalid.
The paper asks for a definition
N3071 suggests that a dedicated notion of constexpr representability may help. It recommends decisions informed by the floating-point study group and notes that some wording may belong in Annex F or Annex G. The proposed direction recognizes that ordinary conversion semantics and acceptance of a constexpr initializer serve different purposes.
As of this paper, the questions remain questions for WG14. They identify gaps in the draft's treatment of complex values, NaNs, and decimal information. An implementer deciding these cases needs a specification that states which distinctions must survive conversion, so independently written compilers can agree about whether the same initializer satisfies the constraint.