Safety profile checks need semantic information about containers

A type with size() and operator[] is not necessarily a zero-indexed sequence. An image may report its storage in bytes while indexing pixels, and a map may interpret the subscript as a key. That is one of the concrete objections in P3543R0, dated 17 December. The response to core safety profiles asks the committee to separate compile-time restrictions from runtime checks and changes to existing behavior. Its argument concerns what information an implementation needs before it can insert the right check.

C++ templates can abstract over types without a runtime layer, but that flexibility makes semantic assumptions important. I am skeptical of inferring an operation's meaning solely from familiar member names. A safety mechanism needs a stronger account of what the abstraction promises.

The original proposal prioritizes adoption in existing code

Herb Sutter's P3081R0 proposes enforced profiles covering several safety categories. Its strategy includes rejecting selected constructs, inserting runtime checks and offering source modernization. It emphasizes obtaining benefits in existing code with minimal manual changes. The paper also explores preserving source spelling while changing the operation performed for selected casts.

That adoption objective addresses a real engineering constraint. A large product may have dependencies it cannot rewrite and interfaces whose owners are elsewhere. A mechanism requiring extensive source changes can leave important code outside the improved mode. The proposal tries to reduce that barrier through compiler-supported enforcement and correction.

The response does not treat all of those mechanisms as one decision. Its authors favor language subsetting in principle, while identifying additional specification work for scope and suppression. They object more strongly to runtime changes and mandated modernization. This makes the disagreement more specific than a general choice between supporting safety and preserving compatibility.

Restricting accepted source has a clear compatibility model

P3543R0 uses the term language profiles for restrictions on which programs compile. Under that model, removing the restriction does not change the accepted program's runtime meaning. The profile identifies source that requires attention or explicit exemption. A program accepted with and without the restriction retains the same behavior.

This is a useful property for libraries compiled in different environments. A caller can reason about the meaning of an operation without first discovering whether another translation unit selected a profile. The profile can affect whether the source is accepted while the interface continues to describe the same operation.

Scope still needs definition. A restriction can concern a declaration, an instantiation or a particular use. A suppression written at one of those locations may not naturally cover the others. The response asks for those rules to be specified carefully, because a fine-grained escape is useful only when developers can predict which operations it exempts.

My preference is for that relationship to be visible in diagnostics. A rejected operation should identify the rule and the relevant scope. Otherwise, a maintainer can end up widening a suppression simply to discover which part of the program the checker considers responsible.

A container check needs to know its indexing domain

The response's container examples show a different problem for automatic instrumentation. A sparse structure, a ring or an automatically growing container can have a subscript contract different from a contiguous sequence. A test comparing an argument with size() can reject valid operations if the returned size describes another quantity.

The image example makes this concrete without needing a complicated implementation. A size measured in bytes and an index measured in pixels have different units. Comparing them directly can be wrong even if both use the same integer type. The compiler needs semantic information about the operation, not merely compatible expression syntax.

An interface-specific contract can supply that information. A type can describe which keys or positions it accepts and how it reports invalid access. A generic mechanism can then use the declared relationship. Inferring the relationship from names would make the safety check dependent on a convention the type never promised to follow.

This is also relevant to existing library checks. The response notes that an implementation might already check its subscript precondition. Automatically adding another inferred check could duplicate work or enforce a different condition. The specification needs to decide which contract is authoritative and how the two mechanisms interact.

Runtime failure handling overlaps with contracts

P3543R0 asks that inserted checks coordinate with the contracts work. Its concerns include handler selection and evaluation semantics. A separate profile-specific handler model would need a defined relationship with the proposed global contract-violation mechanism. Assuming that the two can be reconciled later leaves an important part of the runtime behavior unspecified.

The response suggests separating runtime-checking work or expressing it through the contracts mechanism. It also discusses default-enabled checks with explicit disabling as another direction. These are proposals from the response's authors, not decisions already made for C++26. The common requirement is a coherent description of how a failed check affects execution.

For application design, this behavior matters as much as the predicate. Logging and continuation have different consequences from termination. A check whose predicate is correct can still introduce a new operational policy. That policy belongs in the feature's contract rather than being treated as an implementation detail of a source restriction.

Automatic correction changes the review question

The cast discussion exposes another distinction. A source restriction can reject a cast and require the author to choose a replacement. A silent semantic change can retain the spelling while performing another operation. An offered source patch makes the proposed change reviewable, but a mandated transformation still needs a sufficiently reliable rule.

The response asks for modernization to be considered separately from language subsetting. Some corrections depend on context and can have more than one reasonable outcome. A compiler's ability to suggest an edit is not evidence that every such edit has a uniquely correct meaning for the application.

The practical contribution of the response is to identify these different guarantees. A language subset can constrain accepted source while preserving its meaning. Runtime instrumentation needs the actual operation's precondition and a failure policy. A modernization changes source and needs a reviewable account of the intended replacement. Keeping those requirements explicit gives the committee concrete work to resolve before one profile label can promise all of them.