To help some of us follow, which specific goal posts have you seen moved?

-- Gaby



________________________________
From: SG21 <sg21-bounces_at_[hidden]> on behalf of Ryan McDougall via SG21 <sg21_at_[hidden]>
Sent: Tuesday, October 14, 2025 6:39:21 PM
To: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Cc: Ryan McDougall <mcdougall.ryan_at_[hidden]>; sg15_at_[hidden] <sg15_at_[hidden]>; sg21_at_[hidden] <sg21_at_[hidden]>
Subject: Re: [isocpp-sg21] [isocpp-sg15] P3835 -- Different contract checking for different libraries

Apologies if I've conflated the topic under discussion -- but I do feel like the goalposts have been shifting noticeably...

I would support being in an TS if I felt there was something to learn. In all the time we've discussed contracts in SG21 and voted in SG21 and EWG and Plenary, the points of contention have remained the same, and the consensus trade-offs have remained the same. Alternatives have been suggested piecemeal and largely turned down for good reasons. I don't believe TS would achieve anything meaningful other than delay improvements to Functional Safety/application hardening, giving organizations less reason to use C++.

Sincerely,

On Tue, Oct 14, 2025 at 2:14 PM Ville Voutilainen <ville.voutilainen_at_[hidden]<mailto:ville.voutilainen_at_[hidden]>> wrote:
On Wed, 15 Oct 2025 at 00:10, Louis Dionne <ldionne.2_at_[hidden]<mailto:ldionne.2_at_[hidden]>> wrote:
> But, just to be clear, many large adopters will need the ability to select the observe semantic in order to deploy this at a large scale. That's an extremely useful tool to have. I don't care if that's not called a "Hardened Implementation", but it should be possible.

I'm quite certain they will want to select observe for specific cases,
like the one that the paper mentions,
vector::operator[] where you invoke it for e.g. the use case
&vec[vec.size()]. I do not think they want an observe semantic
library-wide,
because that will just give them UB for the cases where no such benign
case exists.

> TLDR: I think the first wording suggestion in your paper makes sense. That makes only `enforce` and `quick_enforce` be valid evaluation semantics for Hardened Implementations and removes `observe`. Contracts and hardening are still useful with the Contracts MVP, and they'll be more useful once we have additional Contracts features like tagging. That's not a reason to kill either.

That's debatable, but this paper is indeed not about whether there's
reasons to kill contracts.

Which, by the way, nobody has suggested. Moving contracts to a non-IS
ship vehicle doesn't kill them.