On Mon, 2 Jun 2025 at 21:20, Peter Bindels via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:

These concerns were discussed at length in WG21 during the development of P2900 (Contracts for C++). Unfortunately, that discussion is not public, so can't be shared. The P2900 design is intended to allow implementors to provide options for such performance improving transformations. There are ABI considerations in providing multiple entry points with regard to parameter passing or what it means to take the address of the function.

For reference, a discussion on how you could implement P2900 with benefits for checked contracts, without breaking use from compilers that do not check the contracts can be found in P3267. It does indeed likely give the same benefits as this proposal. I do still see a difference in that this `assure` proposal would consider both calls to be in-contract, but one of them to choose a faster path, while P2900 considers one to be out-of-contract.

I will say that that is a very thin advantage and adding a full language keyword plus syntax for such a thing IMO is not worth it.

I don't see a need for more in-source syntax to opt-in to the benefits this proposal seeks. I instead recommend investigating how to achieve the advantages described above as details of a P2900 implementation; e.g., hack on the gcc or clang P2900 implementation to see what can be achieved and what limitations are imposed.

It would indeed be very welcome to have an implementation of P3267's approach #3, so that we can find out in reality how much it affects bloat, code size, speed etc.

It's fairly easy to find WG21 members who think it's absolutely
necessary to have "more in-source syntax" to decide the difference
between a contract
that scales its behavior from full checking to almost-nothing, and a
contract that scales its behavior from full checking to almost-nothing
and onwards
to assumption of the condition stated in the contract.

I assume you are referring to an in-source mechanism to select a contract semantic along the lines of those proposed in P3400 (Controlling Contract-Assertion Properties). If so, I agree.

My statement regarding not seeing a need for more in-source syntax is based on a perception that [[assume(expr)]], inline functions, and a facility to control the contract semantic (whether in-source or otherwise) suffices to provide the benefits the proposer seeks.

Tom.

 There are WG21
members do did see, and continue to see, the muddling of the two as a
complete
showstopper problem for a C++ contracts facility and found the C++20
contracts unacceptable due to that muddling.

The P2900 design doesn't allow for the latter. It envisions some
implementation providing such functionality, as a possibility, but
such functionality
isn't conforming, and isn't actually supported by the P2900 design.