From 23dc3b2cbb541e84e13ccc11f1ab017cb1792133 Mon Sep 17 00:00:00 2001
From: Vito <5780819+Tapanito@users.noreply.github.com>
Date: Tue, 2 Jun 2026 12:58:51 +0200
Subject: [PATCH] docs: Correct XRPL_ASSERT_IF comment on guard evaluation

The previous wording claimed guard is always evaluated in release builds,
but a side-effect-free guard may be optimized away when the assertion
body is a no-op. Reword to warn callers not to rely on side effects
rather than making an unconditional evaluation guarantee.
---
 include/xrpl/beast/utility/instrumentation.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/xrpl/beast/utility/instrumentation.h b/include/xrpl/beast/utility/instrumentation.h
index 7326e8d60e..a8bd2f398f 100644
--- a/include/xrpl/beast/utility/instrumentation.h
+++ b/include/xrpl/beast/utility/instrumentation.h
@@ -41,8 +41,9 @@
 // * XRPL_ASSERT_IF(guard, cond, message) fires the assertion only when guard
 //   is true (e.g. an amendment is enabled). Equivalent to
 //   `if (guard) XRPL_ASSERT(cond, message)` but safe to use in all statement
-//   contexts. NOTE: guard is always evaluated — even in release builds where
-//   the assertion itself is stripped — so keep it side-effect-free and cheap.
+//   contexts. NOTE: do not rely on side effects in guard — in release builds
+//   the assertion body is stripped, and the compiler may optimize away a
+//   side-effect-free guard entirely.
 // * ALWAYS if cond must be true _and_ the line must be reached during fuzzing.
 //   Same like `assert` in normal use.
 // * REACHABLE if the line must be reached during fuzzing