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) <https://wg21.link/p2947> 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
        <https://jasoncc.github.io/gnu_gcc_glibc/gnu-ifunc.html> 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 <https://wg21.link/p2947>.

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

Tom.