Last week, I attended the spring 2024 meeting of the ISO C++ standardization committee in Tokyo, Japan. This was the third meeting for the upcoming C++26 standard and my first meeting as assistant chair of SG 9, the study group for ranges.

Trip Report: Spring ISO C++ Meeting in Tokyo, Japan

by Jonathan Müller

From the article:

I started the week on Monday in LEWG, the working group for the C++ standard library design. After the usual papers adding/extending std::format (Victor Zverovich keeps us busy), we approved a proposal that adds thread attributes, and reviewed the library parts of P2900 contracts. LEWG being LEWG, we mostly complained about the names (std::contracts::contract_violation has too many contracts in it), but overall liked it. However, contracts are a language feature, and the real controversy was over at EWG, the language design group. In particular, what happens if you have undefined behavior in a precondition? Consider the following example:

std::string_view slice(std::string_view str, int pos, int length)
pre (0 <= pos && pos <= std::ssize(str) && 0 <= length && pos + length <= std::ssize(str))
{
return std::string_view(str.data() + pos, str.data() + pos + length);
}

A slicing function for std::string_view using signed integers for demonstration purposes.

An integer overflow of pos + length in the precondition is undefined behavior. Some argue that this should instead be well-defined and lead to a precondition violation. While this would be nice and can lead to a general "safe mode" of C++ which could (and should!) be usable outside of contracts as well, I don't see how it can be worked out before C++26. I'd much rather have contracts with undefined behavior in C++26 then delaying it even further. The nice thing about undefined behavior is that it can be always well-specified later.