On Wednesday, 5 July 2023 19:00:29 PDT trtaab trtaab via Std-Proposals wrote:
> Regarding the term "silent crash," I apologize for any confusion caused. By
> "silent," I meant the absence of any output through stdio, not to be
> confused with a complete absence of any indication of a crash. The
> intention is to avoid any additional output that may be generated by the
> standard library, such as error messages or debug information, while still
> terminating the program in a controlled manner.

Then don't use __builtin_trap, because the traps that it generates can be
caught (on Unix systems, by installing a handler for SIGABRT) and then produce
a non-silent output.

> In response to your suggestion of adding assertions to the operator[]
> method, I acknowledge the potential benefits it may offer. However, doing
> so could lead to One-Definition Rule (ODR) violations when multiple
> versions of the container, with and without assertions, are used within the
> same program. This could cause conflicts during linkage and introduce
> ambiguity in the behavior of the program.

That's a fair argument, though one that in reality (stepping outside of the
standard) only applies to debug-mode code, which is when you want this. It
does mean there's some value in having an extra method that does assertions
and keeps operator[] assertion-free.

However, that value is minimal and may be smaller than the cost of requiring a
single NDEBUG state. Compare that to the cost of modifying the source code to
use this new method.

I also posit that this would be useful as a debugging tool, but the extra
checks should be removed in release mode. This would require that either those
are assertions controlled by NDEBUG or similar mechanisms (thus creating the
ODR problem again) or that the developers would ned to call different functions
in debug vs release mode, which is not acceptable.

Maybe what we need is a refresh of assert() to require it not to be an ODR
violation in the first place. If it were replaced with a builtin of its own
  __builtin_assert(boolean_expr, message);
the compiler could decide to emit code or not emit code under its own control.
Furthermore, it could also use the expression in release mode as an
optimisation hint (__builtin_assume).

> The proposed silent_at method provides a separate interface that
> specifically addresses the need for efficient bounds checking while
> allowing developers to choose the appropriate level of safety for their use
> cases. By introducing a distinct method, we can ensure clarity,
> consistency, and compatibility across different implementations and use
> scenarios.

I think you need to explore the "allowing developers to choose" portion first.
You're basing your proposal on something that doesn't exist, but if it did it
wouldn't need your proposal in the first place. Moreover, that control could be
of great value in other places.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering