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 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 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 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 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 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 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 Bit permutations

This proposal adds