Well, the "compiler vendor" in two major cases are open source projects. I
don't believe anyone in particular has promised to make sure the quality of
implementation lives up to our expectations in this specific case. That is
a matter for faith and clear communication for most of us who are users of
compilers but not contributors as such.

But from a technical point of view, I haven't heard anyone say we should
feel concerned about the difficulty in authoring quality implementations at
some point.

It's good for all of us to remember that ISO WG21 is not the executive
board of C++. Wording in the standard mostly help coordination across
implementations and, to some degree, coordination between users and
implementations.

All that being said, I'll pick a small nit with what I hear from some
people upthread (apologies if I'm overinterpreting anyone!). These issues
of quality of implementation are *not* out of scope for WG21 anymore. We
are creating an Ecosystem International Standard -- a vehicle that is
appropriate for addressing large swaths of issues like this and a lot of
existing wink-and-nudge in the language standard. It does need bootstrapped
in some cases, but I believe it's appropriate to consider large language
changes incomplete at this point if they do not have a good story around
how they will affect the C++ ecosystem.

As I've said upthread, I think it's specifically appropriate to circle back
on the intersection between Contracts and debug information. It's a subset
of the general issue with diagnostic information including sensitive data.
That issue can be addressed with reports and perhaps even standards for the
ecosystem. If Contracts was a more niche feature or if we couldn't fairly
circle back with a good solution to these concerns, I would feel
differently.

Bret

On Wed, Nov 15, 2023, 08:57 Joshua Berne <berne_at_[hidden]> wrote:

> 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.
>