⏩ P3899R1 Clarify the behavior of floating-point overflow
Here, the almost comical compiler divergence for floating-point arithmetic
during constant evaluation is addressed.
Some compilers consider overflow not to be a constant expression, some do.
There are also some major wording issues.
The design is to standardize the GCC behavior:
floating-point overflow (to infinity) is not a constant expression,
and neither is an invalid operation that produces NaN,
nor an operation on signaling NaN;
anything else is fine, such as underflow.
SG6 forwarded the paper and so did EWG.
I would expect this to be in C++29.
However, the overarching task of fixing the floating-point specification is not anywhere near done.
Little to no work has taken place here in 30 years, and it's showing.
⏳ P3969R0 Fixing `std::bit_cast` for types with padding bits
The paper deals with the problem that some uses of
std::bit_casthave undefined behavior for all inputs.
That is because padding bits are mapped into non-padding bits in the destination.
This paper was seen by LEWG before the meeting, and by EWG during the meeting.
Interestingly, there seem to be conflicting opinions:
LEWG is concerned about silently changing the behavior of
std::bit_cast,wheras EWG does not want another flavor of
std::bit_cast (like the paper propses).The common ground here is that
std::bit_cast should be made safer,which can be done by adding a
static_assert that checks for unconditional UB,without changing the behavior of the function otherwise,
and without proposing any additional function.
That will be the direction for the paper going forward.
⏩ P3935R0 Rebasing `<cmath>` on C23
The goal is to introduce all the new C23 functions added to the
<math.h> header into C++.SG6 gave some feedback and forwarded to LEWG.
SG22 still needs to examine the paper.
✅ P3924R1 Fix inappropriate font choices for "declaration"
This paper resolves NB comment US 11-400.
There is no designing here, only fixing some bugs in core wording.
The paper was accepted into C++26.
✅ P4037R0 Supporting `signed char` and `unsigned char` in random number generation
This paper resolves NB comment RU-272.
The problem is that using
std::uniform_int_distribution<std::uint8_t> is undefined behavior,but producing random 8-bit integers is useful, especially for fuzz testing.
The paper was accepted into C++26.
✅ P4052R0 Renaming saturation arithmetic functions
This paper resolves NB comment FR-026-265.
The names
add_sat and saturate_cast are not great,and the paper renames them to
saturating_add and saturating_cast, respectively.This creates consistency with the naming scheme that Rust uses for such operations,
and it chooses the globally most popular naming scheme for saturation arithmetic.
I honestly expected the rename to be far more contentious,
but it seemed like no one in LEWG strongly preferred the old names.
Thus, the was accepted into C++26.
✅ CWG3129 Clarify which *floating-point-literals* are valid
Compilers diverge on whether the literal
1e100000000000000000000000000000000000000000000000f is valid;GCC and Clang consider it to be infinity, and MSVC considers it invalid.
While the wording is clear, the design is accidental fallout from a previous core issue.
I got the impression that not much would happen (and who knows when)
if I didn't get involved.
EWG also looked at the floating-point clarification paper the same meeting,
so this CWG issue was a perfect fit.
At break-neck speed, on Friday, SG6, EWG, then CWG looked at the issue
and merged it into C++26 with no changes.
The key argument in favor of treating this literal as infinity
is that it would otherwise be invalid at the lexer level,
so not even some
if constexpr test involving