On Fri, Jun 10, 2022 at 11:34 AM Lénárd Szolnoki via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Also, I would like to add that this is nothing more than trading one language quirk that happens to be an optimisation barrier to an other (volatile vs function calls across TUs). If we deem optimization barriers to be useful for debugging/benchmarking, then having them as attributes makes perfect sense.

The principle difference is that barriers (language or library) are
way more comprehensible and *searchable* than `volatile` gymnastics.

There are two ways that a programmer will find out about these sorts
of things. Either they read them in someone else's code, or they try
to do something that doesn't behave as expected. For the former case,
it is as previously stated completely incomprehensible without knowing
way too much about C++ esoterica. For the latter case, consider the
previous example in its pre-fixed form:

```
void foo(int *p) {
  if (!p) { printf("null pointer\n"); }
  *p = 0;
}
```

The expectation of most C++ programmers is that this will do what it
looks like it does: if `p` is NULL, they should see a message. That it
doesn't is surprising.

Given that surprise, the user's question now becomes "what should I do
to fix it?" If your answer is "insert a completely unrelated
`volatile` variable between the two statements and read from it;
reading from this completely unrelated variable will magically fix it
for a bunch of esoteric reasons," I shouldn't have to explain why
that's a *bad* answer. An answer of the form `std::optimize()` or
`[[no_optimize]]` or whatever that is at least semi-self-documentation
would be preferred.

Trading an incomprehensible language quirk for a comprehensible one is a win.