Trip report: Summer ISO C++ Meeting in Varna, Bulgaria

Last week, I attended the summer 2023 meeting of the ISO C++ standardization committee in Varna, Bulgaria. This was my first meeting since the pandemic and the first meeting as official member thanks to think-cell's participation in the German national body. In total, 18 different countries sent representatives and over 180 C++ experts attended, although some of them only remotely.

I started the week on Monday in SG-9, the study group for ranges. Although we at think-cell have our own ranges library, we nevertheless want to integrate with the standard and re-use their facilities (if we don't have a better implementation). We are particularly interested in P2846 - std::ranges::size_hint by Corentin Jabot. Some ranges cannot provide an exact std::ranges::size, but an approximate size that is most likely correct. The paper mentions Unicode case folding (which mostly converts code points to other code points, but can also expand a single code point into multiple), but we would also use it for our formatting ranges, which e.g. convert integers to range of characters. With a facility that provides an approximate size, we can reserve memory in containers before appending the range; currently, we can only do that for sized ranges.

On Tuesday morning, I had my own paper to present in EWG P2881 - Generator-based for loop, the working group for language proposals. Barry Revzin and I set out to solve the performance issues with coroutines and the usability issues of iterators: When you just want to use the for loop with an object, adding iterators requires annoying boilerplate and using std::generator and co_yield adds overhead. At think-cell, we solved that with a concept we call "generator ranges": This is a function that receives a callback and invokes it with every element of the range. The big downside of this approach is that you cannot use the range-based for loop—you have to use tc::for_each instead. So we proposed an additional transformation of the range-based for loop that turns the body into a callback which is then passed to a generator range. While EWG was interested in solving the general problem, they were united against that particular approach due to concerns for complex implementation overhead for (seemingly) little gain. After the presentation, I was approached by many people expressing interest and offering advice. We will probably come back with a different solution.

I then stopped by LEWG, the working group for library proposals. What I originally intended to be a quick visit turned into a two-day discussion about the SIMD proposal P1928 by Matthias Kretz. It proposed the addition of std::simd<T>, a wrapper over the SIMD instructions of the CPU. By the time I joined LEWG, they had already discussed the return type of its operator== (should it return bool like any other operator== or should it return std::simd_mask, which is essentially a SIMD of bool?), but there still was a lot of specification left to go over. After discussing it for Tuesday, Wednesday, and Thursday morning, with many small interface tweaks, renames (we changed the name for what is now std::simd_flag_default 3 times), and late-night wording changes (I was volunteered to help out, since I had proposed many of them...), we finally forwarded it to LWG, the next stage. So unless something drastic comes up, C++26 will provide access to SIMD in portable C++.

As I had spent most of my time in LEWG by that point anyway, I stayed there for the last two days as well. Another proposal we forwarded was P0843 - static_vector by Gonzalo Brito Gadeschi et al (now called std::inplace_vector), a std::vector like container with dynamic size but fixed compile-time known capacity. Like many others, we also have an implementation of that, so we might be able to replace it soon by a standard-library one.

Other events of note included an evening discussion of general LEWG policy to prevent re-litigation of small design choices over and over again (but nothing concrete yet), we adopted the C++ features P2169 - A nice placeholder with no name and P2741 - User-generated static_assert message both by Corentin Jabot, and made progress on P2561 - A control-flow operator by Barry Revzin, which proposes something similar to Rust's ? operator for non-exception based error handling. While reflection wasn't talked about at this meeting, I've heard rumors that there might be some movement soon...

I've left Varna with a swim in the Black Sea and ideas for more proposals, so I'm looking forward to the next meeting.