Date: Tue, 14 Oct 2025 17:19:02 -0400
On Tue, Oct 14, 2025 at 5:14 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:
> On Wed, 15 Oct 2025 at 00:10, Louis Dionne <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.
>
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).
> > 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.
Louis
ville.voutilainen_at_[hidden]> wrote:
> On Wed, 15 Oct 2025 at 00:10, Louis Dionne <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.
>
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).
> > 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.
Louis
Received on 2025-10-14 21:19:29
