P3641R0
Rename std::observable to std::observable_checkpoint, and add a feature-test macro

1. Introduction

[P1494R5] "Partial program correctness" introduced so-called observable checkpoints into the language, as well as the function std::observable to establish such a checkpoint in the program.

Three issues with the name std::observable have been brought up ([Reflector], [Reddit]):

• It doesn’t express intent very well, and a longer name could do that better.

• Some associate it with the "observer" design pattern, but it is unrelated.

• It is a short name, and using it for observable checkpoints now may impede future standardization.

1.1. How did it end up being called std::observable?

The name originated in P1494R0.

LEWG last discussed the name during its review of P1494R2 ([TeleconMinutes]). Alternative names (including std::observable_checkpoint) came up during that discussion, but LEWG did not poll names. The minutes of LEWG’s review of P1494R3 do not record a discussion of names.

Note: This does not mean to imply that LEWG neglected its duties. [P1494R5] itself does not discuss alternative names or request naming feedback.

EWG reviews did not poll names, and their minutes do not record a discussion of names. No further discussion of names occurred until the plenary vote at Hagenberg 2025.

Considering the situation, a name change should be polled before Sofia 2025. This needs to be done via paper or national body comment because [P1494R5] has already been approved in plenary.

2. Design

In discussions, std::observable_checkpoint has emerged as a favorite suggestion. It is a very good name because it is self-explanatory:

std::observable_checkpoint() establishes an observable checkpoint.

This expresses intent as elegantly as std::unreachable, which documents that a point in the program is unreachable (or else ...).

Note: Various other options such as std::checkpoint have been discussed. std::observable_checkpoint is proposed because it’s most likely to achieve consensus.

std::observable on its own makes little sense because it’s not trying to say that a point in the program is observable, or that it is observable behavior. Instead, std::observable is a checkpoint for prior observable behavior. This intent should be expressed in the function name.

Furthermore it has been suggested in [Discussion] to add a feature-test macro for the library function. After all,

• there is a __cpp_lib_unreachable macro, and std::unreachable and std::observable are similar,

• [P1494R5] adds no feature-test macro for observable checkpoints (and it shouldn’t), and

• it is useful to know whether the std::observable_checkpoint function exists.

Note: I was unable to find any discussion of a feature-test macro in meeting minutes, so lack thereof may be an oversight, rather than conscious design.

3. Proposed wording

The following changes are relative to [N5001] with the changes in [P1494R5] applied.

In subclause [intro.abstract], modify the note attached to paragraph 5 as follows:

[ Note: A call to std::observable_checkpoint ([utility.undefined]) is an observable checkpoint. — end note ]

In subclause [utility.syn], modify the synopsis as follows:

// [utility.undefined], undefined behavior
[[noreturn]] void unreachable() noexcept;
void observable_checkpoint() noexcept;

In subclause [version.syn], add a feature-test macro as follows:

#define __cpp_lib_observable_checkpoint 2025XXL // freestanding, also in <utility>

In subclause [utility.undefined], modify the declaration of std::observable() as follows:

void observable_checkpoint() noexcept;

    Effects: Establishes an observable checkpoint ([intro.abstract]).

4. Acknowledgements

Thanks to Mark Hoemmen for researching § 1.1 How did it end up being called std::observable?.