A declaration such as `extern double sqrt(double) [[unsequenced]];` tells the compiler it may make stronger assumptions about calls to that function. The assertion belongs to the programmer: the function definition must justify it. Removing the attribute from valid code must not change the program’s semantics. section 16.3 section 16.0
For a pure function without pointer parameters or a pointer return, the check is direct: its return value depends only on its argument values, and it has no effects beyond returning that value. In particular, an `[[unsequenced]]` function must not read nonconstant global variables or system state. **TAKEAWAY:** Verify the function, not merely its declaration, before adding the attribute. section 16.3 section 10.2.3
System state can be easy to overlook. Floating-point behavior may depend on a rounding mode that changes between calls, even when a function appears to perform only arithmetic. A claim that repeated calls are interchangeable therefore needs its floating-point assumptions checked. section 16.3
double g (double y[static 1], double const x[static 2]) {
// We assert that distance will not see different states of the floating
// point environment.
extern double distance (double const x[restrict static 2])
[[unsequenced]];
y[0] = distance(x);
...
return distance(x); // Replacement by y[0] is valid.
}
The example calls `distance(x)`, stores the result in `y[0]`, and later returns `distance(x)`. Its local `[[unsequenced]]` declaration asserts that the calls will not see different floating-point states; under that assertion, the later call can be replaced by `y[0]`. section 16.3
The attribute is not limited to functions with no pointers. With pointer parameters or pointer returns, possible interference with a call is limited to objects visible through those pointers; the pointer-free purity test alone is not enough. C23 also provides the double-underscore spelling `[[__unsequenced__]]` for macro-safe use in headers. section 10.2.3
