On Wed, Jul 5, 2023 at 10:41 PM 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.

Well then there's a problem: the standard cannot mandate any of that.
Outside of diagnostics required for ill-formed code, the standard
cannot mandate any particular thing beyond the bounds of the behavior
of the program. And whether there is "additional noise or debug
information" is well outside of the observable behavior of a program.

So the term "silent" implies a behavior that the standard cannot guarantee.

Furthermore, it's a *bad* guarantee. If the code is built in debug
mode, that "additional noise" is absolutely desirable by every
programmer who is building in debug mode. So for all useful purposes,
it is only "silent" in certain build modes.

So at the end of the day, this function would be *at best* a hint at
implementations on what they should do.

I see no reason why we shouldn't just wait for contracts instead of
inventing new functions that employ a bad version of them.