Cross-posting to SG15 and SG21.

My goal with this email is to encourage collaboration between SG21 (Contracts) and SG15 (Tooling) on the contracts MVP well in advance of the design being presented and potentially approved by EWG.

SG23 (Safety and Security) discussed P2947 (Contracts must avoid disclosing sensitive information) yesterday and agreed that SG15 (Tooling) should address these concerns.

Some regular attendees of SG15 have expressed concerns that a contracts design (the MVP) might be accepted for C++26 without adequate tooling consideration thereby potentially leading to a situation like we have now with modules where we have a language feature with significant adoption challenges. I share some of these concerns.

The following are concerns that I have in mind that are relevant to tooling and that I believe will benefit from SG15 involvement.

  1. Use of contracts in production environments:
    1. Such use will be constrained, independently of the costs of the contract checks themselves, if enablement imposes considerable overhead.
    2. Such use will be constrained if enablement requires rebuilding code for different build modes (ignore, observe, enforce) or for different enablement labels (default, audit).
    3. Such use will be constrained for applications that have dependencies on packages provided by package managers. Package managers are unlikely to provide separate contract-disabled and contract-enabled builds, nor are system package managers likely to provide multiple builds (they don't provide separate assert-disabled and assert-enabled builds today for example). Use in production will require means to provide packages that, at run-time, can have any of the contract semantics (ignore, observe, enforce) enabled at load-time. This capability would require very low overhead means to enable such selection at load-time. Existing linker technologies like the GNU ifunc extension to ELF might pave the way to low overhead solutions.
  2. Discoverability of contract check labels/levels, particularly in situations where contract checks can be dynamically enabled.
  3. Protection of sensitive information per P2947.

Please reply with any additional concerns. I believe papers, probably targeting SG15 and the ecosystem IS, will eventually be desired.

Tom.