On Thu, 6 Jul 2023 at 02:56, trtaab trtaab via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Dear Jason McKesson,

 

Thank you for your response and bringing up the topic of contracts. While the proposed "silent_at" method shares similarities with contracts in terms of enforcing bounds checking, there are some key distinctions to consider.

 

Contracts, as currently implemented in the libstdc++ library, can be computationally expensive due to the additional overhead introduced by passing parameters to the contract violator and the use of exception throwing for the contract terminator. Furthermore, contracts may generate output, which can include additional debug information that some developers prefer to avoid.

 

The "silent_at" method, on the other hand, aims to provide a more lightweight and efficient alternative. Its primary objective is to perform bounds checking while ensuring a completely silent crash without any output.


This is useless to most developers. A mysterious and silent crash is the opposite of helpful.

 

By utilizing mechanisms such as __builtin_trap() in GCC and Clang, the method offers a controlled program termination without producing any additional garbage or debug output.

 

This distinction is particularly important for developers who prioritize performance and optimization, as well as those who prefer a minimalistic approach without the overhead of exceptions or unwanted output.


Since you're already looking at libstdc++, I'm surprised that you've missed the fact this is already possible. If you don't want exceptions, compile with -fno-exceptions and vector::at will call abort() on bounds errors.

Or compile with -D_GLIBCXX_ASSERTIONS to enable precondition checking, which will make vector::operator[] perform bounds checking and abort. If you really want minimal output to give a silent crash with no useful info (and slightly less code on executed when aborting) then you can configure GCC with --disable-libstdcxx-verbose so that an assertion failure just calls abort() with no additional output to stderr.

So what you want is already doable as a Quality of Implementation matter. I doubt the committee will ever support adding new functions to the standard library to support this "fail fast and quietly" use case. Very few people want that, and if they do want it, they can get it already.

 

 

If the committee finds merit in exploring this proposal further, I would be grateful for the opportunity to discuss potential alternatives and gather additional insights from committee members and the wider C++ community.

 

Thank you for your consideration, and I am open to any further questions or discussions on this topic.

 

Sincerely.

 

Sent from Mail for Windows

 

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals