On my way back from #WG21 in Croydon/London. #cpp26 is done. Notable change that I got through: You don't have to wonder anymore what difference there is between `constant_arg` and `constant_wrapper`. Only the latter remains. And `constant_wrapper` now works as a function-wrapper, too (passing a callable as constant expression via function argument).
And—somewhat sad—but `simd::vec<float>(...) * 2` won't compile anymore. I'll have to update GCC16 accordingly.

The first part of std::simd just landed in #GCC 16: https://forge.sourceware.org/gcc/gcc-mirror/commit/8be0893fd98c9a89bbcd81e0ff8ebae60841d062
Expect it on Compiler Explorer in — I guess — 12 hours.

#simd #wg21 #cpp #cpp26 #cplusplus

libstdc++: Implement [simd] for C++26 · 8be0893fd9

This implementation differs significantly from the std::experimental::simd implementation. One goal was a reduction in template instantiations wrt. what std::experimental::simd did. Design notes: - bits/vec_ops.h contains concepts, traits, and functions for working with GNU vector builtins t...

Sourceware Forge: Core Toolchain and Developer Tools

What's the constexpr-if equivalent to `condition ? x : y`? As far as I know we only have `[&] { if constexpr (condition) return x; else return y; }()`. I hate it.

#cpp #cplusplus #WG21

Can we fix the following inconsistency in #CPlusPlus: https://compiler-explorer.com/z/qsYeTncE4? A conversion operator is sufficient to call wrapped function pointers. But it does not work for wrapped callable objects. And that's even though `wrapper` in the above example has the callable type in its associated namespaces (ADL). ADL was introduced to make operators work. I patched my #GCC to make it work and I like it.

#WG21 #cpp29 #cpp

Compiler Explorer - C++ (x86-64 gcc (trunk))

template <typename T> struct wrapper { T value; constexpr operator const T&() const { return value; } #if 0 constexpr decltype(auto) operator()(auto&&... args) { return value(args...); } #endif }; int f1(int); auto f2 = [](int x) { return f1(x); }; int test1() { return wrapper{f1}(1); } int test2() { return wrapper{f2}(1); }

Virtual Trip Report: WG21 Kona 2025

After the CD (committee draft) is out, WG21 is in bug fixing mode. Consider NB comments as the tickets that force us to consider a resolution and provide an answer. Such issues can either be design issues or wording issues (where wording does not match stated design intent). Besides NB comments, many library issues had been filed and prioritized independently, which led to several categorized as must/should fix before the standard is finalized.

Vir’s blog — go fast with readable code!

Last week meant survival mode. Attending the #WG21 meeting in Kona, Hawaii *virtually* meant Zoom sessions from 19:00–04:00. With family in the house, some of them sick, my priority was 1. not getting sick 2. getting the work done. So no 🏊🚴🏃 last week.

1/1

#weightlifting #traininglog

C++は常に進化している! C++26・C++23の新機能と今後のトレンド - Qiita

はじめに C++は3年ごとに新しい規格が策定されていて、2025年11月時点では最新のC++23が各コンパイラで実装されつつあります。 そして、次期規格のC++26も標準化委員会で策定が進んでいます。 今回は、C++23で追加された機能とC++26で提案されている機能をコ...

Qiita

Immediate escalating expressions promote constexpr functions to immediate functions. 👍 Now, can I get a partially promoted half-immediate function instead? 😢

#wg21 #cpp26

I read https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2025/p3802r0.pdf "Poor Functions" last night. I jumped for joy! 😆 Finally, I had words for what I was thinking all this time. This __local_ctx idea puts into words what I wanted to say with regard to #FunctionMultiVersioning (https://gcc.gnu.org/wiki/FunctionMultiVersioning). I need to be able to reflect on those attributes in order to make SIMD types and functions behave correctly in the context of FMV. __local_ctx producing a std::meta::info sounds like the solution!

#WG21 #cpp26 #GCC

There's resistance against using the same name in a namespace and a type inside that namespace. Why? What is the actual problem with this code? Is the 'foo::foo' looking too much like a constructor definition (in that context)? Isn't it great how the call to 'bar' has a clear relation to 'foo'?
Why is it considered bad practice that shouldn't pass code review?

#cpp #cplusplus #WG21 #cpp26 #namingThingsIsHard