On Thu, 6 Jul 2023 at 03:41, trtaab trtaab via Std-Proposals <std-proposals@lists.isocpp.org> 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.