On Thu, 6 Jul 2023 at 03:41, trtaab trtaab via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Dear Thiago Macieira,
>
>
>
> Thank you for your response and additional points regarding the proposal
> for the "silent_at" method. I appreciate the opportunity to address your
> concerns. Please find my counterarguments below:
>
>
>
> The term "silent" in the context of the proposal refers to the absence of
> additional output from the standard library, such as error messages or
> debug information. While crashes are not inherently silent, the use of a
> reliable crash mechanism, whether it's __builtin_trap() or other similar
> methods, is intended to provide a controlled program termination without
> generating extraneous output. The primary focus is on achieving a clean
> crash without introducing additional noise or debug information.
>
>
>
> The inclusion of file and line information in error reporting during
> bounds checking is a common practice in many programming languages and can
> be a valuable tool for debugging. However, the absence of such information
> in the proposed "silent_at" method does not indicate a prioritization of
> performance over correctness. Instead, it is a deliberate design choice to
> cater to developers who prefer a minimalistic approach without any output
> or debugging information.
>

The inclusion of file and line info in crash messages is an implementation
choice, not required by the standard. Some implementations allow it to be
disabled, so that in small embedded environments the program does not need
to contain I/O functions for printing the crash message. So what you want
is already achievable, without new functions.



> This approach is particularly useful in scenarios where developers have
> already ascertained that the indexes cannot be out of bounds and wish to
> eliminate any unnecessary overhead.
>

Then why are they using vector::at if the indices are never out of bound?
Just use vector::operator[]. Even if you use vector::at, others have
already explained how the overhead that it adds is only in the cold path,
which does not affect performance *until* you access out of bounds. And so
your entire proposal is about improving the performance of a crash (and
making it harder to debug at the same time). That's ridiculous. A crash
happens at most once in the entire program's lifetime, and changing APIs of
standard library classes to improve the crash experience is ridiculous.

Adding new member functions for this use case makes no sense.