On Tue, Nov 14, 2023 at 7:05 PM Ville Voutilainen via SG21 <
sg21_at_[hidden]> wrote:

> On Tue, 14 Nov 2023 at 18:36, Tom Honermann via SG15
> <sg15_at_[hidden]> wrote:
> >
> > On 11/13/23 4:59 PM, Timur Doumler via SG15 wrote:
> >
> > Thanks for the summary, Bret!
> >
> > I totally agree that the concern seems reasonable but there doesn't seem
> to be an appropriate ship vehicle at the moment. Addressing the problem via
> the language spec seems like the wrong direction, and addressing it via the
> language spec in just one specific feature like Contracts seems like doubly
> the wrong direction, which is exactly why I believe this would go nowhere
> in SG21 (and not because the concern is unreasonable). Hope that makes
> sense.
> >
> > I agree that the language specification is the wrong place to address
> this with the exception that the language spec has to permit omitting the
> information (which is already the case).
> >
> > If there was a desire to do anything about this, I think the right ship
> vehicle is the ecosystem IS; we could have a section that discusses removal
> of sensitive information. I have no strong opinions about pursuing that
> though.
>
> I don't find it troublesome to specify such information-scrubbing in
> the language spec. I would, however, expect that it's not handled
> as a requirement for a contracts facility, but with a proposal of its
> own that handles contract violation information, source_location in
> general,
> and __FILE__ and __LINE__ and __func__ in a coherent package. Or
> explains why it doesn't.
>

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.

Our original intention was just to drive a small fix into P2811 itself, out
of our concern that:

   1. 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.
   2. Whether real or just perceived (by the wider C++ community), the
   mentioned risk is greatly enhanced with contracts.

This means we would like to see a quick fix, ideally baked straight into
the contracts MVP. We could go for the bigger effort (and I'm not ruling
it out), but that's an all or nothing scenario which might end up with
contracts in C++26 without the fix we're advocating for. And besides,
wouldn't the macros you mentioned also require the extra step of
coordinating such a change with WG14?

_______________________________________________
> SG21 mailing list
> SG21_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
> Link to this post: http://lists.isocpp.org/sg21/2023/11/5534.php
>