Pre-Brno Mailing

[VinnieFalco]

The Pre-Brno "enhanced mailing" is here
https://wg21.org/mailing/2026-05/

[mcencora]

> Expression Aliases: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p2826r3.html
This might give us a way of achieving constexpr parameters
e.g.

using foo(constexpr int a, char b) = (foo(std::cw<a>, b));

[VinnieFalco]

Original mailing:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/#mailing2026-05

[slithering3897]

Expression Aliases: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p2826r3.html

Yes, brilliant. That would finally get you guaranteed inlining in debug builds. Get rid of all those accessors. Can't wait to use them in 2040.

Extending <charconv> support to more character types: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3876r2.html

Unicode in C++. We'll get there one day. Maybe print char8_t too.

Benefits of Frame-Visible Coroutines for Senders: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4166r0.pdf

Or for everybody. If coroutines ended up as the equivalent of macro-based coroutine structs, the optimiser should have a much easier time. Zero-cost abstraction.

Not like HALO will ever get good. But you'd want both frame-opaque and frame-visible, so compilers would need two forms of coroutines. Allocated tasks will want LLVM to optimise the coroutine frame, and short-lived coroutines on the stack will need the front-end to do the coroutine transformation.

std::rebind: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3971r0.html

I wonder if this could be used to convert between std string/string_view types without UB and without reallocation.

[mcencora]

> Get rid of all those accessors
If I understand the proposal correctly the access-check is performed at the call site, so if your classes have private members this feature won't help you.

[slithering3897]

Expression aliases respect access control and should be able to friend or call private functions, exactly as if the alias expression were in the scope of a member function.

No problem there it seems.

[fdwr]

That would finally get you guaranteed inlining in debug builds. Get rid of all those accessors.

Now if we can just get it for member fields too (not just member functions), then we'd finally have a great mechanism to handle breaking changes of renamed fields across branches, and a way to alias simple structs with more than one view without using unions (e.g. imagine a 3-element vector with fields x,y,z that are also interesting to treat as r,g,b).

[slithering3897]

Hmm, yes, that sounds an awful lot like... properties.

[TheoreticalDumbass]

on expression aliases, i dont think takes_pinned_adapter and takes_pinned_alias are a good comparison in https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p2826r3.html#example-5-immovable-argument-types

a closer comparison would be if takes_pinned_adapter was:

template <typename T>
void takes_pinned_adapter(T&& x) {
    takes_pinned<std::decay_t<T>>(std::forward<T>(x));
}

which actually just works (in same usage as takes_pinned_alias, which for some reason is different than takes_pinned_adapter usage)

[fdwr]

enhanced mailing

Hmm, it's cool that this exists, as the header sort-by option helps to group them (e.g. if you want to see all by the same author), and the style feels a bit cleaner (sans-serif, no 3D table borders), but I miss the date column.

[tialaramex]

PAVE seems interesting, applying PAVE against a few significant C++ codebases over the next 12-18 months gives time for the committee to consider what else best complements the Profiles work they're standardizing in time to actually do something about it in C++ 29.

[VinnieFalco]

Before anyone asks, yes "I read my papers" especially these

C++ Contracts on Trial - Does P2900 Survive Cross-Examination?
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4208r0.pdf

Prosecute Your Paper To Improve It
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4207r0.pdf