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.

The pre-Kona WG21 mailing includes N5028 “SoV and Collated Comments,” which is the collation of all 26 National Bodies’ comments on the C++26 CD. Nineteen NBs submitted comments. It is important to note that different NBs have different mechanisms for soliciting their comments. The US NB simply submits every comment it receives — no filter. My impression is that some other NBs (UK? Sweden?) have a technical discussion about every comment and submit only comments that win consensus within the NB.

C++26 is notable for the large number of relatively unimplemented and novel features it specifies; and the NB comments on C++26 are notable for the many comments of the form “We should completely remove novel feature X.” By my count:

In “What breaks without implicit T*-to-bool conversion?” (2025-10-05) I wrote that in a proprietary C++17 codebase my audit turned up “one non-explicit operator bool, and zero bugs.” On closer inspection we found that that non-explicit operator bool actually was causing a real bug! Consider this hypothetical type that behaves something like unique_ptr<int> (Godbolt):

struct IntPtr {
  explicit IntPtr() = default;
  explicit IntPtr(int *p) : p_(p) {}
  int& operator*() const { return *p_; }
  int *operator->() const { return p_; }
  operator bool() const { return bool(p_); }
  friend bool operator==(IntPtr a, IntPtr b) { return a.p_ == b.p_; }

  int *get() const { return p_; }
private:
  int *p_ = nullptr;
};

std::set<IntPtr> myset;
int i, j;
myset.emplace(&i);
myset.emplace(&j);
assert(myset.size() == 2); // fails!

After emplacing two items, myset.size() is only 1!

C++20 took a small step by deciding (via P1957) that a T*-to-bool conversion should be considered narrowing, and thus forbidden in list-initialization. But could we go further and make T*-to-bool conversion non-implicit?

I patched my local copy of Clang to forbid implicit conversion from T* to bool. Here’s all the things that broke when I compiled LLVM/Clang itself with my patched compiler.