Previously: “span should have a converting constructor from initializer_list” (2021-10-03). This converting constructor was added by P2447 for C++26. Way back in 2024, Peter Kasting added the same constructor to Chromium’s base::span — he emailed me about it at the time — but I was only recently reminded that in the /r/cpp thread about the feature he’d written:

Yup, this change was so useful it led to me doing a ton of reworking of Chromium’s base::span just so I could implement it there.

Speaking of ambiguity: out of context that comment could be taken as sarcasm. What programmer enjoys “doing a ton of reworking just” to implement a single new constructor? Did he mean the change was so useful, or, like, “so useful”? :) So it’s worthwhile to track down pkasting’s actual commit from November 2024 and see all the places he sincerely did clean up as a result.

The other week I read William Empson’s Seven Types of Ambiguity (first published 1930, third edition 1953 with new footnotes by the author). Empson purports to taxonomize all sorts of “ambiguity,” defined as any technique or nuance “which gives room for alternative reactions to the same piece of language.” Really I’m not sure I fully grasped his taxonomy. (One might call it a taxonomy of ambiguity in more ways than one!) But it’s something like this:

P1064 “Allowing Virtual Function Calls in Constant Expressions,” adopted for C++20, permits you to mark virtual functions as constexpr and then call them at compile-time. In fact, you can even mark them consteval (also a C++20 feature), which means you can call them only at compile-time. Thus (Godbolt):

I wrote in ”[[trivial_abi]] 101” (May 2018), during the active development of the [[clang::trivial_abi]] attribute:

Relation to trivial relocatability: None… well, some?

As you can see, there is no requirement that a [[trivial_abi]] class type should have any particular semantics for its move constructor, its destructor, or its default constructor. Any given class type will likely be trivially relocatable, simply because most class types are trivially relocatable by accident…

A correspondent writes in with a query for Socrates (previously seen on this blog in July 2023).

Epistolographos writes: Actually, I think trivial-abi-ness and trivial relocatability are almost the same thing.

I recently read, and enjoyed, David Owen’s “The Objectively Objectionable Grammatical Pet Peeve” (January 2023). The objectionable practice in question is what Fowler calls the “sentry participle,” a participle or appositive stuck on the front of a sentence that could just as well have done without it. For example:

Yesterday on the cpplang Slack, someone asked the purpose of std::has_unique_object_representations_v<T>, and someone else pointed to an example given in Steve Dewhurst’s “Back to Basics: Class Layout” (2020). Sadly, that example is incorrect. Let’s take a look.

The other day my wife suggested the idea of KenKen “with letters.” There’s probably an idea in there related to anagrams, somehow; but the first idea that popped into my head was to use Roman numerals. Here’s a “really Latin square” for you to solve:

Previously: “LONG0751 has been found” (no spoilers), “LONG0751: Mysteries of Donovan’s map” (minor spoilers). This post contains major spoilers for LONG0751!

Here’s a weird vendor divergence recently spotted on the cpplang Slack. Consider a function template foo, where instantiating the body of foo<int> will give an error. For example:

At the end of 2025 I got the usual thing in the mail saying that my Sirius XM car-radio subscription was going to renew and replace my current promotional price ($107.88/year) with the standard monthly price ($24.98/month). So, as usual every year, I called Sirius to get the promotional price back.

Again this year, I kept a record of the media that I took in — in the sense of books, films, stage shows, journal articles, magazines, TV series, and (to a much lesser extent) long-form online content. (Last year’s post is here.)

Previously: “LONG0751 has been found” (2025-12-29). This post contains partial/minor spoilers for LONG0751!

Back in 2021 I announced the rediscovery of a text adventure named Castlequest (Mike Holtzman and Mark Kershenblatt, 1980). This month another “lost game” has been found: David Long’s 751-point Adventure!

Lately libc++ has been adding the C++17 [[nodiscard]] attribute aggressively to every header. (I’m not sure why this month, but my guess is that libc++ just dropped support for some old compiler such that all their supported compilers now permit the attribute even in C++11 mode.) libc++ is following the trail that Microsoft STL has blazed since VS 15.6 in late 2017.

Big news of the week, via Hacker News: Someone has engineered a 1D spaceship in Conway’s Game of Life! That is, there exists a pattern which initially fits into a bounding box of dimensions \(3\,707\,300\,605\times 1\) — that “1” is what makes it “1D” — and, when evolved for \(133\,076\,755\,768\) steps, reforms itself into exactly the same pattern shifted two cells to the left.

In C++, when we have a type that carries no data — whose only “identity” is its type — we conventionally call that a “tag type.” When you see code like struct X {}; it’s often the case that X is a tag type. However, not all tag types are created equal: there are at least two major disjoint use-cases for tag types, and the STL (as of 2025) therefore uses two distinct naming conventions for their identifiers.

There is no widely recognized nomenclature for these two kinds of tag types, as far as I know, so I’m going to call them disambiguation tags and concept tags.

C++20 added atomic_ref<T> to the Standard Library (see “Guard nouns or guard verbs?” (2023-11-11)). But somehow C++20 overlooked atomic_ref<const T>; it’s finally permitted in C++26, thanks to Gonzalo Brito Gadeschi’s P3323. But then there was a new problem: since const T& binds to both lvalues and rvalues, suddenly it is legal to write

This afternoon I presented a paper at the quarterly meeting of the “Three Garridebs,” Westchester’s scion society of the Baker Street Irregulars. Here it is for posterity, almost entirely as delivered (minus a brief ad-lib apology for its being more about Miss Marple than about Sherlock Holmes).

The Kona WG21 meeting was two weeks ago. This was the (first) big “resolve NB comments for C++26” meeting. Last month I wrote about some of the NB comments, and whether they might actually lead to removal of the offending features. Well, big news: P2786’s non-trivial “trivial” relocation was successfully removed in Kona, satisfying the 6+ NB comments that asked for that removal! This is good news for everyone who uses trivial relocation today, and I’m very happy that we finally got enough “adults in the room” (read: library implementors) to make the right call. Of course we’ll probably do it all over again for C++29. See below.

In the pre-Kona WG21 mailing is P3858R0 “A Lifetime-Management Primitive for Trivially Relocatable Types” (std::restart_lifetime) (Sankel, Bauman, Halpern). A correspondent asks for my thoughts on it.