On Wed, 15 Oct 2025 at 00:19, Louis Dionne <ldionne.2_at_[hidden]> wrote:
> That's not my experience. My experience is that you have hundreds of projects across an organization. You build all projects with `observe` and you run tests, use the software, etc. That allows you to figure out what projects are violating preconditions as part of QA, and you file bug reports for said projects to fix their violations as you move along. As you're making progress, you move more and more software to an actual terminating semantic.
>
> So it's not about being able to observe some assertions but not others: it's about the ability to observe all assertions within a given part of your code (e.g. a complete dylib or application), and to gradually switch them from observe to enforce (or quick_enforce).

Good luck doing that. You're not going to be able to observe all
assertions within a given part of your code when they hit UB.

The exercise you describe works when the code is written so that it
tolerates the contract violations, so that after you hit a
precondition
violation, you can without any problems hit a second one. That's not
the case for the stdlib code.

>> > 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.
>
>
> "Kill" might have been a poor choice of words on my end, but you get the point.

I do indeed. There are people who simply disagree with that take of
yours, because to them, various promises of the MVP aren't met.
Which then makes it not V.