Even setting contract behavior for translation units would run into issues, if code is inlined (e.g. templates) or link-time-optimization is applied. So for a good solution (with clean module or library boundaries) syntax for behavior is needed instead of just command-line switches.   -----Ursprüngliche Nachricht----- Von:Jonathan Wakely via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 02.04.2026 13:04 Betreff:Re: [std-proposals] Benchmarking contract evaluation semantics mode "assume" in Eigen. An:David Brown <david.brown_at_[hidden]>; CC:Jonathan Wakely <cxx_at_[hidden]>; C++ Proposals <std-proposals_at_[hidden]>;   On Tue, 31 Mar 2026 at 09:05, Jonathan Wakely <cxx_at_[hidden] <mailto:cxx_at_[hidden]> > wrote:  And since the version of contracts we have in C++26 only allows them to be enabled globally or disabled globally, for the whole program, you don't get to choose which API boundaries have checks enabled and which don't. So you can't use contract checks as performance hints in your code without disabling checks at API boundaries between untrusted (or less trusted, or less tested) components.  I was asked about this statement off-list, and should clarify what I meant.  Contracts in C++26 do allow an implementation to provide more granularity so that different assertions (or different TUs, or different libraries) can use different evaluation semantics. But what was standardized for C++26 (the Minimum Viable Product of C++ Contracts) doesn't provide any syntax or other mechanism for doing that.  So what I wrote isn't really accurate. C++26 does *allow* them to be enabled or disabled non-globally, but just allowing it doesn't actually make it possible. You can't do it in portable C++26 code. And you can't do it in the implementation that's about to ship in GCC 16 (adding support for labels as an extension could be added in future, but isn't supported today).   So if you absolutely require the ability to use different evaluation semantics in different places (and many people do require that), then you'll need to wait for C++29 which is expected to provide features for doing that. It was always made clear that C++26 contracts would not provide every feature on day one, and that some use cases would be supported later. They're still useful for other use cases today, just not all use cases.      -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals