On Wed, Nov 15, 2023 at 8:10 AM Andrei Zissu via SG21
<sg21_at_[hidden]> wrote:
> Our original intention was just to drive a small fix into P2811 itself, out of our concern that:

There is no "quick fix" that gives you anything resembling what you
seem to want. P2811 has, since first conceived, certainly always
been designed to make an implementation that strips such information
perfectly conforming exactly to support this use case, and there is
not much more the Standard can or should say on the subject.

  As multiple groups have now told you, the standard has no way to
express normatively what you seem to desire, as it has none of the
concepts that could define what stripping the data from the binary
might mean.

As multiple groups have also told you, the scope of the problem you
bring up is beyond Contracts and any solution to the problem needs to
be addressing the actual problem and not just some perceived small
facet of the problem --- in particular, just because such a change
might involve WG14 as well is not a reason that the wrong change
should be made.

As multiple groups have also told you, implementations can and will do
what you are asking for. At the implementation level, where binaries
are produced and bits are put in those binaries, the requirements you
specify make complete sense and can be expressed and guaranteed.
Whether that is separate filtering steps or built into the compiler is
functionally irrelevant -- certainly nothing we put in the standard
would preclude separate tools to accomplish specific tasks either.

> A contracts MVP without this opt out might create an unfavorable reputation for contracts and hamper their adoption, which may be hard to bounce back from later.
> Whether real or just perceived (by the wider C++ community), the mentioned risk is greatly enhanced with contracts.

Such an unfavorable reputation can only come from people repeatedly
spreading misinformation about what the C++ standard is and is not.
All of the PR you are talking about should be handled in release notes
from the compiler vendors --- and certainly could be handled in such a
way as long as you do not continue to keep saying to the world that
the C++ Standard shoudl somehow say things that make no sense on the
context of that document.

> Either way I would indeed prefer this to be in the language spec rather than in the tooling ecosystem, due to my understanding (am I wrong?) that the latter option would imply a "scrubbing" mechanism, as in preparing the final binary and then running an additional (possibly non-standard?) tool that would remove this information. This feels to me both awkward (why not just refrain from putting the sensitive texts in there to begin with during compilation?) and harder to do, since the final binary might lack the contextual information necessary for safely and efficiently determining what is to be removed.

You are wrong in assuming that anything we say in the standard could
dictate that a platform would not conform by providing a "scrubbing
mechansim" or separate tool --- these are all concepts outside the
standard and which exist as part of conforming implementations. No
"quick fix" in the standard is going to be capable of solving this
perceived set of problems. Getting the right contextual information
to the right place is an implementation detail that every compiler
vendor has told you would be accomplished regardless of what we
specify.