On Wed, 15 Nov 2023 at 15:10, Andrei Zissu <andrziss_at_[hidden]> wrote:
>> 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.

I don't think it implies that. It's just that in some ways it's easier
to specify the omission of source/etc. information in a standard that
specifically
talks about tools and their interfaces than in a standard that
specifies a programming language.


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

No, such a coordinating step isn't necessary. C++ has a C++
preprocessor, if we want to say it has a mode that leaves out source
information,
we can do that without WG14's blessing. It's a separate question
whether you'd want that ability to be present in C as well.