Library requirements need to specify what happens when they fail

A library requirement can mean that an overload should disappear, that compilation must produce a diagnostic, or that a call has violated a runtime precondition. Those consequences are different even when a specification places their conditions under the same heading. Walter Brown's P0788R0 proposes separating them as the library prepares for concepts and contracts.

The WG21 paper index records the paper on October 10 in the October mailing. It is a proposal for specification practice. It does not itself announce that every existing standard-library requirement has been rewritten or that contracts have become an implemented language facility.

I favor this distinction because a generic interface needs to tell a caller more than whether its arguments are acceptable. The consequence of failure determines whether another overload can be selected, whether the build is rejected or whether execution has left the function's supported domain. Those are materially different agreements.

An unavailable candidate need not be an error

Brown proposes a Constraints element for conditions governing participation in overload resolution. If a candidate's constraints are not satisfied, that fact does not require a diagnostic by itself. Another candidate may be the appropriate function for the arguments supplied.

There can still be a consequential error. If every candidate is unavailable, overload resolution may fail and produce a diagnostic. The important distinction is that failure to satisfy one candidate's constraints does not independently make the entire program invalid. This lets a library offer alternatives with different requirements.

That is different from placing an assertion in a selected function's body. A body-level rejection happens after the interface has participated in selection. It cannot be treated as the same overload policy simply because both approaches reject some argument types eventually.

The proposal connects this to familiar wording saying a function does not participate in overload resolution. A dedicated element can describe the intended effect directly instead of hiding it in an additional remark. Concepts offer one way to implement that effect, but the requirement is about which candidates the program can use.

Required diagnostics describe a different obligation

A proposed Diagnostics element describes conditions that require a compiler message when not satisfied. Brown gives static_assert as a possible implementation technique. The specification can state the consequence without prescribing that exact mechanism.

This matters for generic code that tries alternative expressions. A condition intended to make a program ill-formed is stronger than one intended only to remove a candidate. If the specification leaves the distinction unclear, two implementations could appear to offer the same signature while exposing different behavior to surrounding templates.

Brown argues against simply redefining the old Requires element to mean a new subset of its former uses. His proposed migration introduces new elements and aims to replace the old ones systematically. That avoids giving unchanged specification text an unexpected new interpretation merely because its heading has been reused.

Preconditions concern the state when a call executes

The proposed Expects element describes conditions a function may assume when invoked. Violating those conditions leads to undefined behavior unless the specified exception behavior provides otherwise. This concerns a call's supported domain, which may depend on runtime values and object state.

The companion Ensures name replaces the traditional postconditions heading in the proposed terminology. It describes observable conditions established on successful return. The names align with the contracts proposal's vocabulary, but the library's specification obligation remains separate from whether an implementation uses contract attributes to express it.

The earlier P0542R0 contracts wording demonstrates why that separation matters. It discusses checks with different build levels and a violation handler. A library specification still needs a defined caller obligation even when a particular build does not execute every check.

The standard can specify an effect without mandating the machinery

P0788R0 explicitly permits implementations to meet overload constraints with a requires-clause, enable_if, compile-time branching or other techniques. It likewise permits different mechanisms for diagnostics and contract-like checks. A program should rely on the specified effect, rather than assuming the library's private implementation uses one particular facility.

That approach preserves implementation freedom while making observable distinctions more precise. A compiler or library can improve its internal machinery without turning an unavailable overload into an unconditional error. The specification's categories identify which effect must survive such a change.

The paper also asks how to express constant-expression guarantees and how to audit the existing library wording. Those are open questions, not completed conversions. Applying the proposed categories consistently requires examining existing requirements and separating clauses whose conditions have different consequences.

I consider that audit more important than the heading names themselves. The useful result is that a reader can identify whether a condition controls candidate availability or a selected call's validity. New language facilities can then implement those policies without forcing the library specification to expose one particular implementation strategy.