On Thu, 6 Jul 2023 at 02:56, trtaab trtaab via Std-Proposals <
std-proposals_at_[hidden]> 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 <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>