Do I understand that correctly that you are talking about getting gains with inlined functions by giving additional static (constexpr expression) constraints at the call-site?   Why is it better (except syntax) compared to existing facilities?   -----Ursprüngliche Nachricht----- Von:SD SH via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 01.06.2025 15:19 Betreff:[std-proposals] A Proposal about A New Keyword assure An:std-proposals_at_[hidden]; CC:SD SH <Z5515zwy_at_[hidden]>; This proposal introduces a new contextual-keyword assure that allows callers to declare parament Constraints at function call sites. can utilizing these Constraints to optimize function calling. (e.g. removing branches) Violations result in undefined behavior. Analogous to [[assume]].   Motivation         Check-ups of function definition sites is unnessary at some call sites, but compilers may preserve check-ups for them. Sometimes we need more performance optimizations but we can't do many optimizations such as built-in functions and third-party libraries.         e.g. Lighting computing will call sqrt many times.         If sqrt(double _X) like this:             double __fastcall sqrt(double _X)             {                 if(_X < 0.0)                 {                     return std::numeric_limits<double>::infinity();                 }                 else                 {                     // ...                 }             }             // asm:             /*                 _sqrt:                     pxor xmm1, xmm1                     ucomisd xmm0, xmm1                     jl _sqrt__Xl0                     ; ...                 _sqrt__Xl0:                     movsd xmm0, 0x7FF8000000000000                     ret             */         In lighting computing, _X is always equals zero or greater than zero, so branch of if(_X < 0.0) is never performed there, but compiler may not remove it.         assure will slove this issue.         sqrt(d assure(d >= 0)) may generates             _sqrt:                 pxor xmm1, xmm1                 ucomisd xmm0, xmm1                 jl _sqrt__Xl0             _sqrt_sometime:                 ; ...                 ret             _sqrt__Xl0:                 movsd xmm0, 0x7FF8000000000000                 ret             ;...             movsd xmm0, [somewhere]             call _sqrt_simetime         or inline call or a new function of sqrt, we needn't program another sqrt for this call site and compiler can optimize program better. Design Decisions     Syntax         func(para1 assure(const-bool-expr(INPUT: { para1, const paras... })), paras...)           Rejected Alternatives:             func(paras...) assure(const-bool-expr(INPUT: const paras...))                 makes compiler implementation difficult.         Semantics:             Constraints are purely caller-to-compiler optimization hints.             Expressions must be side-effect-free and dependent only on caller-visible state.             Expressions should be true, or function calling has undefined behavior         Alternative Considered:             Runtime assertions (for security) rejected due to performance impact.       Ecosystem Impact         User:           Performance gains with constraints         Implementers:   Medium or low implementation effort         STL:            Greater room for optimization   View the full text (R0) on GitHub: CPP-Proposals/assure.txt   Thank you!   E. S. Himers <Z5515zwy_at_[hidden]> -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals