Contract diagnostics can disclose information before they run
P2947R0 asks implementations to let users omit contract text and locations from shipped binaries, separating failure reporting from disclosure policy.
A diagnostic string can disclose information even if the failure that would print it never occurs. If the text is embedded in a distributed binary, someone examining that binary can read it directly. July's contracts paper P2947R0 asks the C++ design to account for that distinction.
The paper, dated July 17, comes from Andrei Zissu, Ran Regev, Gal Zaban, and Inbal Levi. It responds to Joshua Berne's P2811R7 on contract-violation handlers. The requested change is an implementation-provided way to omit meaningful contract text and source-location information.
I regard diagnostic detail as part of an interface's design. The detail can make a failure understandable, but it also becomes information that the product carries. A contracts facility should let its users distinguish information useful inside their build system from information they intend to distribute.
Empty properties and removable information differ
P2811R7 allows contract-violation information to include a comment and a source location. The comment describes the predicate, while the location helps identify where a violation was detected. These properties support useful reporting by a violation handler.
P2947R0 observes that allowing an implementation to leave the properties unpopulated is weaker than requiring an implementation to provide an opt-out. Without the latter requirement, a conforming implementation could always populate the properties and give users no supported way to remove the information.
The proposal therefore makes availability of the opt-out part of conformance. It leaves the mechanism unspecified. A compiler flag is a plausible implementation choice, but the paper does not propose a standardized flag spelling.
That separation is useful. The standard can require a capability while implementations integrate it into their own build models. Users then have a portable expectation that the choice exists without assuming that every compiler presents it through the same command line.
The scope also extends beyond returning an empty string from an accessor. The authors want the information absent from the binary, unless another requirement needs it, or at least no longer associated with the contract in a way that reveals its location and meaning. Suppressing output alone would leave the binary-inspection concern unresolved.
Locations can describe more than one site
The paper notes that source-location information can identify call sites as well as the annotation itself. A precondition associated with a function can therefore lead to text describing several callers. The amount of embedded information can exceed the single expression visible beside the function.
This matters because a release build can carry useful semantic clues without conventional debug information. File names and function names can direct an analyst to relevant code. Predicate text can explain the relationship that the programmer expected to hold.
The authors do not claim that removing those strings prevents reverse engineering. Their argument concerns the additional assistance supplied by names and descriptions. The proposal aims to preserve a user's ability to control that assistance.
That qualification keeps the security claim proportionate. Omitting contract text is a disclosure-policy choice, not a memory-safety guarantee or a general protection against inspection. The program's behavior and machine instructions remain available to the person who possesses the binary.
Less detail creates a real diagnostic cost
The authors acknowledge that removing the information makes it harder to identify the violated annotation. They argue that users should be able to choose that tradeoff. Knowing that a contract violation occurred can remain useful even when its full text is unavailable.
The paper discusses crash dumps and separately retained symbols as partial ways to recover context. It also mentions debugging a violation handler and observing the call stack. These techniques depend on the environment and available evidence, so they do not erase the diagnostic cost.
For me, the important requirement is to make the cost deliberate. A production build can favor restricted disclosure while an internal build retains richer failure reports. That policy should be expressed in supported build behavior, not achieved accidentally by hoping a diagnostic never executes.
The same distinction applies to logging interfaces generally. Choosing where an event is written and choosing which explanatory strings enter the executable are different decisions. A handler controls runtime reporting, while the build determines what the distributed artifact contains.
The proposal preserves contract checking
P2947R0 does not ask to remove the underlying contract checks. Its concern is the descriptive information attached to a violation. That allows the checking mechanism and the disclosure policy to remain separate design questions.
This also explains its adoption argument. The authors report that some vendors expend considerable effort removing textual information from products. If contracts require shipping that information without an opt-out, those vendors may avoid the facility in production.
A useful design can therefore support checking while allowing a reduced-information report. July's paper asks implementations to make that choice available. The remaining contract semantics and the eventual standard interface remain subjects of proposal work, while the binary-disclosure problem is stated independently of whether a failure is ever logged.