It would be good to keep the syntax aligned and carefully compare using modes for contracts or new keywords / attributes.   -----Ursprüngliche Nachricht----- Von:Peter Bindels via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 27.03.2026 09:57 Betreff:Re: [std-proposals] [[assume_assert(expr)]] and/or evaluation semantics mode "assume". An:std-proposals_at_[hidden]; CC:Peter Bindels <dascandy_at_[hidden]>; P2900 is focused on (functional) safety first and foremost. Any assume semantic does not make sense, and adding that to the discussion will muddle the story on what contracts bring first and foremost.  That said, the concept of an assume semantic is well-understood, and many are indeed asking for it. I suspect that compilers will be implementing it even if the C++ standard does not mention it, and users will be trying it out, and finding that for correct invocations it indeed works the same (modulo compiler bugs), while for buggy calls it can have terrifying optimizations applied based on them not happening.  It is probably a good idea to write a paper to propose specifically only the assume semantic, and to defend that in WG21 with lots of actual performance data from a code base that uses P2900/C++26 contracts extensively, to show what its impact is and why that should warrant being standardized. You will likely get a big discussion on safety, but for "release builds" as colloquially known they should be effectively what we have done before. On Fri, Mar 27, 2026 at 5:29 AM Adrian Johnston via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: We have P2900 in the works and it is moving us away from the "roll your own" situation we have been in with respect to asserts for the last 37 years. So ergonomics is part of it. And as far as I know, P2900 specifies an evaluation semantics mode without defining how a macro would be defined in terms of the current evaluation semantics mode. That is one barrier. The other issue is that the [[assume]] attribute prohibits function calls which is an issue with global blanket use. (clang has -Wno-assume for function calls in __builtin_assume, gcc had no satisfactory solution for that in my tests.) Lastly, I think the proposal I am trying to float here encourages more safety around the use of "assume" semantics. This is because it provides a way to check your assumptions in a debug build. And safety is all the rage these days. On Thu, Mar 26, 2026 at 8:22 PM JJ Marr <jjmarr_at_[hidden] <mailto:jjmarr_at_[hidden]> > wrote: > > I'm a big fan of the idea. Why isn't a macro of an assertion followed by an assumption sufficient? > > On Thu, Mar 26, 2026, 5:41 p.m. Adrian Johnston via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: >> >> Hello, >> >> I would like to propose [[assume_assert(expr)]] which would be a >> hybrid of contract_assert and [[assert(expr)]] that selects between >> the behavior of the two depending on the evaluation semantics mode as >> described in P2900: >> >> - ignore: same as [[assume(expr)]] >> - observe: same as contract_assert(expr) >> - enforce: same as contract_assert(expr) >> - quick-enforce: same as contract_assert(expr) >> >> These have the benefit of alerting the developer in a debug build when >> [[assume(expr)]] has been misused and hopefully reduce the amount of >> undefined behavior associated with the use of [[assume(expr)]]. >> >> As an alternative to this approach, an evaluation semantics mode >> "assume" could be added which would convert all P2900 contract >> assertions to have [[assume(expr)]] semantics. >> >> proposed evaluation semantics: >> - ignore: unchanged >> - observe: unchanged >> - enforce: unchanged >> - quick-enforce: unchanged >> - assume: replace pre(expr), post(expr), post(ret, expr), >> contract_assert(expr) with [[assume(expr)]] semantics. >> >> The one major issue here is that the current standard says an assume >> statement cannot call functions, and this limitation would not be >> enforceable across a non-trivial application. Instead, I would propose >> that function calls would result in the expression being ignored when >> evaluation semantics are set to mode "assume". In this case a warning >> would not be recommended as that would break strict builds. >> >> I have implemented this kind of [[assume_assert(expr)]] using >> compiler-specific intrinsics and used it for every last assertion in a >> non-trivial codebase. It worked great, and so I am recommending it for >> the next version of C++26. >> >> I would also like to suggest things like assume_pre (expr) and >> assume_post (expr) although that pollutes the global namespace for a >> feature that is less commonly used. >> >> My recommendation would be to add [[assume_assert(expr)]] and >> evaluation semantics mode "assume". >> >> Regards, >> Adrian >> -- >> Std-Proposals mailing list >> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals