2024-07-10
integration into IS ISO/IEC 9899:202y
| document number | date | comment |
|---|---|---|
| n3298 | 202407 | remove tg features |
| factorize the syntax | ||
| n3241 | 202404 | original proposal |
CC BY, see https://creativecommons.org/licenses/by/4.0
The current integration of complex types into the C standard is a bit half-hearted:
there are no complex literals
basic operations such as computing real and imaginary part or the complex conjugate are delegated to functions that cannot be used in contexts where arithmetic constant expressions are required.
A discussion during the June 2024 remote meeting was not able to produce consensus on the form of the feature as it was proposed in n3241, and the arguments given often seemed to have mixed up the “i” that is used as a literal suffix and I, the macro.
One important objection that was brought forward against the original paper was that it was too restrictive compared to existing practice, which basically allows all combinatoric of combination of complex suffix and binary floating point.
By combining _Generic, casts to real types and complex arithmetic it is easy to provide expressions that result in the real, imaginary, complex conjugate and complex projective values, and that are suitable as arithmetic constant expressions. But these are not as easy to implement as it seems at the first sight, because they should properly take care of border cases such as imaginary parts that are positive or negative zeros, infinities or NaNs. The original paper proposed type-generic features in <tgmath.h> but we removed this because there was no consensus, yet. Our intent is to repropose this later, once the dust of the changes concerning imaginary types and Annex G has settled.
Several modern C compilers (gcc, clang, XL C) already have suffixes with i or j for complex literals since decades. In general, similar to the suffix component u for unsigned integer literals, i and j may precede or follow f and l and capitalized versions are also supported.
<complex>Users coming from different backgrounds will have different expectations; in particular probably about the half of the community that intensively use complex types come from engineering and signal processing; there the convention is to use a “j” or “J” suffix. Since the compilers with these features already support the full combinatorics of these suffixes, we propose to integrate this convention into C2y as is.
Removals are in stroke-out red, additions in underlined green.
In p1, change the current definition of the term floating-suffix to real-floating-suffix and add a new definition for that term and for complex-suffix.
f l F L df dd dl DF DD DL
floating-suffix:
real-floating-suffix complex-suffixopt
complex-suffix real-floating-suffixopt
complex-suffix: one of
i I j J
In the “Constraints” section change and then add at the end or after p2 (at the discretion of the editors):
A real floating suffix df, dd, dl, DF, DD, or DL shall not be used in a hexadecimal floating constant. A floating suffix shall not designate a type that the implementation does not provide.
Modify the beginning of paragraph p5
The presence of a complex suffix indicates that the type of the literal is the complex type that corresponds to the type of the literal where the complex suffix is removed. The described floating value of such a complex literal designates the imaginary part of an arithmetic constant expression of the indicated complex type, the real part is (positive) zero.FNT) An unsuffixed floating constant has type
double. If suffixed by a real floating suffix it has a type according to the following table: …
FNT) Implementations that define the macro __STDC_NO_COMPLEX__ may not support complex types. For these implementations, a literal with a complex suffix presents a constraint violation.
These strtoXXX and wcstoXXX functions all refer to “floating constant” but should never designate a complex value if an “i”, “I”, “j”, or “J” follows a real floating constant. For backwards compatibility, parsing of the number should always stop before such a character. Change all of these occurrences in these clauses
… real floating constant …
Note that in other clauses, the term “floating constant” is appropriate and should not be changed.
Note also that with already voted changes the term will soon be “floating literal” instead of “floating constant” and the changes proposed here should be applied analogously.
Change the beginning of p2 to
This subclause expands real-floating-suffix (6.4.4.2) to also include: …
Add a new note after p7 to
NOTE 2 It follows from here and from 6.4.4.2 that the valid combinations of such an expanded real float suffix with a complex suffix correspond to the supported complex types as described in H .2.5.