On Wednesday, 5 July 2023 19:30:44 PDT trtaab trtaab via Std-Proposals wrote:
> The main objective of the "silent_at" method is to cater to individuals who
> prioritize specific safety requirements without incurring unnecessary
> costs.

I understand what you're saying but I disagree that you are achieving what
you're saying. I would say that developers who want safety don't want the
application to unexpectedly abort at runtime. They would instead want to prove
that the indices are in-range.

Moreover, safety is as strong as the weakest link, implying that all portions
of the code must have the same guarantees that you're requesting here. That
being the case, I'd argue that requiring the same NDEBUG setting is an
acceptable solution, because one wants the same setting everywhere.

> By avoiding the printing of information during bounds checking, the
> "silent_at" method aims to prevent any violations of the zero-overhead
> principle and ensures that users only incur the desired safety features
> without additional overhead.

But you're *not* avoiding it. You're moving it from the function in question
to another place. As I said, there is such a thing as signal handlers on Unix
systems, and on Windows the Structured Exceptions Handlers will probably get a
chance to run too. Plus, the OS itself may print something; the Linux kernel
will print to dmesg:

[85956.064610] traps: selftest_sigill[135660] trap invalid opcode ip:459b15
sp:7f43c4c00ce0 error:0 in opendcdiag[406000+4a9000]

In fact, you're making it worse, because __builtin_trap will cause a SIGILL on
Unix systems and that signal by default is a core dump, which is not a
negligible operation and worse if your application has a large memory space.

> The presence of at() and operator[] already creates dialects in the
> codebase. However, it's worth noting that the widespread use of the
> -fno-exceptions flag in the C++ community prevents the utilization of the
> at() method altogether. This limitation further reinforces the need for an
> alternative method, such as "silent_at," that caters to users who cannot
> rely on exceptions in their codebase due to compile-time configurations.

I again agree with the facts as you've stated, but not with the conclusion.

In summary:
- I agree that there is a problem to be solved
- I disagree with your choice of solution (adding a new method)
- I disagree with the name you chose for that method
- I argue that the implementation you've provided does not match what the name
  implies

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