Stay up-to-date with everything C++!
Content directly fetched from the subreddit just for you.
Join our group for discussions : @programminginc
Powered by : @r_channels
Post #24261
12
Progress report for my proposals at Kona 2025
Hey, I thought you may be interested in how some of my proposals did during Kona 2025.
## Accepted
##### [P3774R1](https://isocpp.org/files/papers/P3774R1.html) Rename `std::nontype`, and make it broadly useful
Despite the name, all this proposal does is rename the tag `std::nontype`
to `std::constant_arg`.
This was already accepted during a telecon prior to Kona with pretty high consensus.
An unfathomable amount of committee time has been spent on something that ended up being a pretty simple decision.
Even so, it wasn't unanimous, and there is a chance that people will want to change it back or use `std::constant_wrapper`, so nothing is actually set in stone.
##### [P3836R2](https://isocpp.org/files/papers/P3836R2.html) Make `optional<T&>` trivially copyable
While R0 and R1 aimed to give some additional guarantees regarding the layout of `optional<T&>`, this idea was incredibly unpopular.
It was all pretty stupid in hindsight.
We ended up going with the simple option of just guaranteeing that `optional<T&>` is trivially copyable, which could have been an LWG issue in hindsight.
## Rejected
##### [P3765R0](https://isocpp.org/files/papers/P3765R0.html) Deprecate implicit conversion from `bool` to character types
The idea in this paper is to deprecate conversions such as `bool -> char`.
While the idea makes sense, EWG really didn't want to have it in the standard without prior implementation experience.
In hindsight, it was pointless to even suggest it without first giving it a trial run in compilers.
It seemed like the room was open to making this a warning in compilers/linters though.
I've since made a feature request for LLVM to have this as a default warning.
##### [P3776R1](https://isocpp.org/files/papers/P3776R1.html) More trailing commas
This paper would have added trailing commas in more places, like
void f(
int x,
int y, // here
);
However, there was no consensus to have this in C++29. There were two technical issues that people pointed out:
1. There is a bit of inconsistency regarding where you can have the commas.
For example, you cannot have it int `static_assert(true,)` or in `using x,y,;`,
and this was perceived as a negative.
2. Trailing commas wouldn't be permitted in definitions of function-style macros,
or in macro expansions,
which can be problematic when functions are potentially defined as macros.
However, I don't think technical problems killed the idea;
I think people's minds were already made up before the discussion began.
People felt that the paper lacks motivation,
and it's hard to convince someone that a feature is useful when they haven't used it for 30 years and they don't immediately think of it as
> oh nice, I could have used this
That being said, there may be ways to get it into C++29 with the right changes, the right people in the room, etc.
## Made progress
##### [P3733R1](https://isocpp.org/files/papers/P3733R1.html) More named universal character escapes
This paper allows you to use `"\N{NBSP}"` in addition to `"\N{NO-BREAK SPACE}"`,
among ~350 extra names.
This is intended to be a DR against C++23, and is in CWG for inclusion in C++29.
Consensus was almost unanimous, so I would expect this to be implemented in compilers next year, basically.
Unfortunately, it couldn't be in C++26 due to procedural issues.
##### [P3666R1](https://isocpp.org/files/papers/P3666R1.html) Bit-precise integers
This proposal adds `_BitInt` from C23 to C++.
Two different study groups have looked at this paper by now,
and the design choices for the core language have unanimous consent from both groups.
This gives me high hopes that we'll have this in C++29.
The big issue is that adding `_BitInt` to C++ as an integer type implies
that there are massive changes to the standard library,
since the standard library has blanket support for integer types in many places.
That will definitely take some time to figure out.
##### [P3014R4](https://isocpp.org/files/papers/P3104R4.html) Bit permutations
This proposal adds
Hey, I thought you may be interested in how some of my proposals did during Kona 2025.
## Accepted
##### [P3774R1](https://isocpp.org/files/papers/P3774R1.html) Rename `std::nontype`, and make it broadly useful
Despite the name, all this proposal does is rename the tag `std::nontype`
to `std::constant_arg`.
This was already accepted during a telecon prior to Kona with pretty high consensus.
An unfathomable amount of committee time has been spent on something that ended up being a pretty simple decision.
Even so, it wasn't unanimous, and there is a chance that people will want to change it back or use `std::constant_wrapper`, so nothing is actually set in stone.
##### [P3836R2](https://isocpp.org/files/papers/P3836R2.html) Make `optional<T&>` trivially copyable
While R0 and R1 aimed to give some additional guarantees regarding the layout of `optional<T&>`, this idea was incredibly unpopular.
It was all pretty stupid in hindsight.
We ended up going with the simple option of just guaranteeing that `optional<T&>` is trivially copyable, which could have been an LWG issue in hindsight.
## Rejected
##### [P3765R0](https://isocpp.org/files/papers/P3765R0.html) Deprecate implicit conversion from `bool` to character types
The idea in this paper is to deprecate conversions such as `bool -> char`.
While the idea makes sense, EWG really didn't want to have it in the standard without prior implementation experience.
In hindsight, it was pointless to even suggest it without first giving it a trial run in compilers.
It seemed like the room was open to making this a warning in compilers/linters though.
I've since made a feature request for LLVM to have this as a default warning.
##### [P3776R1](https://isocpp.org/files/papers/P3776R1.html) More trailing commas
This paper would have added trailing commas in more places, like
void f(
int x,
int y, // here
);
However, there was no consensus to have this in C++29. There were two technical issues that people pointed out:
1. There is a bit of inconsistency regarding where you can have the commas.
For example, you cannot have it int `static_assert(true,)` or in `using x,y,;`,
and this was perceived as a negative.
2. Trailing commas wouldn't be permitted in definitions of function-style macros,
or in macro expansions,
which can be problematic when functions are potentially defined as macros.
However, I don't think technical problems killed the idea;
I think people's minds were already made up before the discussion began.
People felt that the paper lacks motivation,
and it's hard to convince someone that a feature is useful when they haven't used it for 30 years and they don't immediately think of it as
> oh nice, I could have used this
That being said, there may be ways to get it into C++29 with the right changes, the right people in the room, etc.
## Made progress
##### [P3733R1](https://isocpp.org/files/papers/P3733R1.html) More named universal character escapes
This paper allows you to use `"\N{NBSP}"` in addition to `"\N{NO-BREAK SPACE}"`,
among ~350 extra names.
This is intended to be a DR against C++23, and is in CWG for inclusion in C++29.
Consensus was almost unanimous, so I would expect this to be implemented in compilers next year, basically.
Unfortunately, it couldn't be in C++26 due to procedural issues.
##### [P3666R1](https://isocpp.org/files/papers/P3666R1.html) Bit-precise integers
This proposal adds `_BitInt` from C23 to C++.
Two different study groups have looked at this paper by now,
and the design choices for the core language have unanimous consent from both groups.
This gives me high hopes that we'll have this in C++29.
The big issue is that adding `_BitInt` to C++ as an integer type implies
that there are massive changes to the standard library,
since the standard library has blanket support for integer types in many places.
That will definitely take some time to figure out.
##### [P3014R4](https://isocpp.org/files/papers/P3104R4.html) Bit permutations
This proposal adds
