Hi all,
this is a report of what is going on with my papers
during the 2026-03 WG21 meeting in Croydon,
and during the telecons leading up to it.
I think this report adds quite a lot of value since the broader-scale trip report by Herb Sutter
tends to focus more on the large features being delivered,
rather than the many smaller improvements I tend to work on.
I've had a great time this meeting,
and made an immense amount of progress.
Many of my C++29 papers made some progress,
and all papers targeting C++26 were accepted.
It was a resounding success.
⏩ P3666R3 Bit-precise integers
This paper introduces
_BitInt(N) types (bit-precise integers) into C++,for compatibility with C23.
The feature made it through EWG with flying colors.
While some of the design was questioned,
such as the ugly
_BitInt keyword andthe not-so-useful limit of
BITINT_MAXWIDTH to be 64 (or LLONG_WIDTH),I did a great job defending the design of the paper,
and it got forwarded to CWG with strong consensus.
In LEWG,
_BitInt could not shed its nature of being a "C compatibility feature",and the proposed library impact of P3666 was deemed way too large.
Consequently, LEWG voted to outright prevent
_BitInt from receiving any library support,and voted for
std::is_integral_v<_BitInt(N)> to be false.In hindsight, the latter restriction goes too far, and I will relitigate it.
std::is_integral_v<_ExtInt(N)> would be true for some N-bit extended integer,if Clang's
_BitInt was still spelled _ExtInt and considered an extended integer type.It makes no sense to treat bit-precise integers differently because
std::is_integral_vis already a blank cheque for the implementation to extend the trait.
In any case, the finish line is in sight.
I think it's possible to forward P3666 from LEWG to LWG next meeting,
and have it in the standard in 2026.
⏩ P3688R6 ASCII character utilities
This one was not seen during the meeting,
but during SG16 telecons before Croydon.
After a bit of back and forth and some design and wording feedback, it was forwarded to LEWG.
⏩ P3695R3 Deprecate implicit conversions between `char8_t` and `char16_t` or `char32_t`
As the title says, the goal is to deprecate some bug-prone implicit conversions.
The paper was forwarded from SG16 during telecons to EWG,
but it would be best to put some more work into the paper and implement the warning
exactly as proposed in Clang before proceeding with standardization.
⏳ P3724R3 Integer division
Before Croydon, LEWG looked at this paper,
which adds several functions such as
std::div_to_neg_inf for integer divisionwith rounding toward negative infinity.
While the overall interface remains contentious
and while some people were missing a
std::div_euclid function (for Euclidean rounding),it should be possible to make progress with a bit more discussion and design adjustments.
LEWG will see the paper again at some point, likely in Brno.
⏩ P3764R0 A utility function for propagating the most significant bit
The paper adds a single
std::msb_to_mask function which "broadcasts" the uppermost bit,i.e. returns a bit mask where every bit has the value of the most significant bit.
SG6 gave some feedback regarding motivation and naming, and forwarded to LEWG.
⏳ P3876R1 Extending `<charconv>` support to more character types
SG16 looked at this paper before Croydon,
and we just barely didn't have time to complete the review.
The paper adds support for
char8_t and other character typesto
std::to_chars and std::from_chars.This is an important stepping stone towards Unicode support in the standard library
because it enables
std::format to work with char8_t format strings in the future as well.I suspect we will finish the review during telecons soon,
and the paper will make it