My intent is to start identifying things to think about. Preloading the
cache as it were. I don't see a need to block this on either feature
completion of the MVP nor a presentation of it to SG15.

So, yes, I'm very much ok with that general plan. I just want to leave
as much runway as possible for consideration of SG15 concerns.

Tom.

On 11/9/23 5:44 PM, Timur Doumler via SG21 wrote:
> Hi Tom,
>
> Thanks. It has always been our intention to reach out to SG15, present
> the Contracts MVP to them, and give them the chance to review it with
> tooling considerations in mind.
>
> However, my original plan was to first let SG21 plug the remaining
> design holes, and then reach out to SG15 as soon as we have achieved
> that, i.e. we don't have any of the yellow "TO DO" boxes left in P2900
> (our Contracts working paper). I think we're not that far away from
> that and we'll get there at some point between now and Tokyo.
>
> Are you OK with this general plan, or do you have a strong preference
> for presenting P2900 in SG15 on a more urgent schedule?
>
> Cheers,
> Timur
>
>> On 9 Nov 2023, at 09:59, Tom Honermann via SG21
>> <sg21_at_[hidden]> wrote:
>>
>> 
>>
>> Cross-posting to SG15 and SG21.
>>
>> My goal with this email is to encourage collaboration between SG21
>> (Contracts) and SG15 (Tooling) on the contracts MVP well in advance
>> of the design being presented and potentially approved by EWG.
>>
>> SG23 (Safety and Security) discussed P2947 (Contracts must avoid
>> disclosing sensitive information) <https://wg21.link/p2947> yesterday
>> and agreed that SG15 (Tooling) should address these concerns.
>>
>> Some regular attendees of SG15 have expressed concerns that a
>> contracts design (the MVP) might be accepted for C++26 without
>> adequate tooling consideration thereby potentially leading to a
>> situation like we have now with modules where we have a language
>> feature with significant adoption challenges. I share some of these
>> concerns.
>>
>> The following are concerns that I have in mind that are relevant to
>> tooling and that I believe will benefit from SG15 involvement.
>>
>> 1. Use of contracts in production environments:
>> 1. Such use will be constrained, independently of the costs of
>> the contract checks themselves, if enablement imposes
>> considerable overhead.
>> 2. Such use will be constrained if enablement requires
>> rebuilding code for different build modes (ignore, observe,
>> enforce) or for different enablement labels (default, audit).
>> 3. Such use will be constrained for applications that have
>> dependencies on packages provided by package managers.
>> Package managers are unlikely to provide separate
>> contract-disabled and contract-enabled builds, nor are system
>> package managers likely to provide multiple builds (they
>> don't provide separate assert-disabled and assert-enabled
>> builds today for example). Use in production will require
>> means to provide packages that, at run-time, can have any of
>> the contract semantics (ignore, observe, enforce) enabled at
>> load-time. This capability would require very low overhead
>> means to enable such selection at load-time. Existing linker
>> technologies like the GNU ifunc extension to ELF
>> <https://jasoncc.github.io/gnu_gcc_glibc/gnu-ifunc.html>
>> might pave the way to low overhead solutions.
>> 2. Discoverability of contract check labels/levels, particularly in
>> situations where contract checks can be dynamically enabled.
>> 3. Protection of sensitive information per P2947
>> <https://wg21.link/p2947>.
>>
>> Please reply with any additional concerns. I believe papers, probably
>> targeting SG15 and the ecosystem IS, will eventually be desired.
>>
>> Tom.
>>
>> _______________________________________________
>> SG15 mailing list
>> SG15_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
> _______________________________________________
> 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/5393.php