P2680R0 argues for contracts with contained side effects

A condition used to describe a function's requirements becomes difficult to analyze if evaluating it can change unrelated program state. Gabriel Dos Reis's P2680R0, dated October 15, makes this a central question in C++ contracts design. He argues for predicates whose side effects remain inside the evaluation, with function arguments and constants supplying their external inputs.

The paper is a design argument addressed to SG21. It does not announce an adopted contracts facility or provide a complete implementation specification. Its contribution is a direction for the semantics that would make contracts useful to code-analysis tools as well as runtime checking. That scope matters because the paper's title advocates safety, while its concrete discussion concentrates on predicate structure and side effects.

I value C++ most where the language makes an obligation visible and gives it a dependable rule. RAII does that for resource release within ordinary control flow. Contracts could help describe other obligations, but only if reading a predicate tells the reader what it asserts without requiring reconstruction of unrelated effects.

Preconditions describe what a function expects

P2680R0 describes a precondition as a predicate expressing a function's expectations of its arguments. A postcondition expresses a guarantee immediately after successful execution. Assertions inside a function express invariants at particular execution points. These are descriptions of program properties at specified boundaries.

That is more specific than saying code runs before or after a function. A prologue can perform arbitrary setup without expressing a precondition. An epilogue can perform cleanup without asserting a postcondition. The paper argues that using those implementation locations as the language model gives analysis tools too little structure.

The distinction affects the meaning of evaluating a contract. A predicate needs enough computational power to express the property, but its evaluation should not become another stage of the application's normal work. If logging or remote communication belongs to the function's intended behaviour, Dos Reis places that work in the function body.

This is an argument about the facility's design, not merely a coding convention. Permitting arbitrary observable effects and advising users to avoid them leaves tools facing the unrestricted language. A language-level restriction can give those tools a stronger premise when interpreting a predicate.

Local mutation is compatible with a predicate

The proposal does not prohibit every side effect. It permits work inside the evaluation as long as the effects do not remain observable outside it. Local counters and temporary computation can help express a property without changing the state whose behaviour the program is meant to describe.

The distinction is between the implementation of a calculation and its externally visible result. A loop can update a local accumulator while computing a boolean. If that accumulator is private to the evaluation, the mutation need not change the state seen by the caller or function body. Updating an external counter or writing a file would have a different effect.

That makes the proposed rule more useful than a prohibition expressed only through syntax. Rejecting every assignment would rule out familiar computational techniques even when their effects are confined. Allowing any boolean-returning function would accept computations with unrelated external behaviour. P2680R0 tries to specify the semantic boundary between these cases.

The paper also proposes requiring definitions of called functions to be reachable at the contract's location. Analysis needs access to the computation it is asked to treat as a predicate. A declaration that says a function returns bool does not reveal what the function reads or changes.

Constexpr provides a model of contained evaluation

Dos Reis refers to the evolution of constexpr as a precedent. Richard Smith's N3652 relaxes constraints on constexpr functions while controlling what may be modified during constant evaluation. That model permits richer calculations without allowing arbitrary mutation of surrounding program state.

The relevance is the separation between local computation and external effects. A constant evaluator can execute multiple statements and local changes while preserving the requirement that the evaluated expression obey its semantic restrictions. P2680R0 suggests adapting that style of model to contracts.

It does not require every called function to carry the constexpr specifier. The paper instead asks for reachable definitions and effects contained within the contract evaluation. Importing the conceptual model is different from requiring exactly the same declarations and execution rules as compile-time evaluation.

That difference limits what examples can responsibly claim. A function accepted by a constexpr implementation is not automatically a contract function under an adopted rule, because P2680R0 has not specified such an adopted interface. The paper gives a foundation for further design. It does not define a portable contracts syntax ready for application code today.

Analysis needs more than a runtime check location

A runtime checker can evaluate a condition and react to its result, but static analysis also needs a useful interpretation of the condition. Dos Reis wants a compiler or analysis tool to evaluate expectations symbolically where possible. Structured predicates give that analysis something stronger than an arbitrary fragment of setup code.

For example, a predicate that only inspects arguments and performs contained calculation can describe a relationship among those arguments. A predicate that consults and changes unrelated global state also depends on a history outside the function's visible inputs. That history makes the supposed summary less self-contained.

The proposal does not claim this structure proves every contract automatically. Rich predicates can still be difficult to reason about. Its argument is that unrestricted observable effects undermine the starting point for sound analysis, so the language should establish a narrower model before adding flexibility.

I prefer that priority for a facility intended to support safety. An annotation is useful when it gives both readers and tools a precise statement about program behaviour. Merely placing arbitrary executable code beside a declaration would not supply the same common meaning.

The paper leaves further semantics to design

P2680R0 does not provide a complete treatment of violation handling, build modes, or compiler optimization based on contracts. Those topics should not be inferred from its advocacy of analyzable predicates. The specific proposal concerns how expectations and guarantees are expressed and which effects their evaluation may have.

Its final technical position is to begin with a model that supports sound reasoning and extend it deliberately. Within that direction, local mutation can remain available as an implementation technique. The observable behaviour associated with performing a function's actual work stays in the function body, while the contract describes the conditions on that work.