Date: Wed, 15 Oct 2025 00:53:03 +0300
On Wed, 15 Oct 2025 at 00:40, Louis Dionne via SG15
<sg15_at_[hidden]> wrote:
> On Tue, Oct 14, 2025 at 4:35 PM Gabriel Dos Reis via SG21 <sg21_at_[hidden]> wrote:
>>
>> The point is that hardened standard library implementations are being delivered right now, today, for supported language versions, without being phrased in term of P2900, by GCC, Clang, MSVC, etc.
>>
>> Any rephrasing in terms of P2900 should bring tangible benefits over what is available today. I see none.
>
>
> I don't think that is accurate. Libc++'s implementation of hardening is basically as close as possible to Contracts without actually using the language feature. We provide `enforce`, `quick_enforce`, `observe` and `ignore`, which can be selected using macros. We allow users to customize the handlers for `enforce` and `observe` in a way similar to what Contracts proposes. All of these decisions basically came from deployment experience and user feedback / feature requests (in particular observe, which we didn't have originally). IMO, that demonstrates a tangible benefit of wording hardening on top of Contracts, backed by libc++'s experience. Folks are free not to believe it, but it is historically and factually accurate that libc++ ended up where it is due to user demand and real world constraints. It's also the case that this has been deployed at a large scale and documented.
But that's still not phrased in terms of P2900. There's a difference
between how that thing works, and how it would work when phrased in
terms
of P2900 using actual contract assertions. You have there a
libc++-specific separation from any code using P2900, until you
possibly choose
to remove that separation. It turns out that separation is actually
useful, and in some cases, very useful.
And that's not a question of belief. There are actual reasons for such
a separation, and those have been observed (ha ha) in the wild.
> By the way, I'm not disputing that other standard libraries also provide useful hardening-like modes that are not built on top of Contracts. But that doesn't make what I said above untrue.
Sure, agreed, in spirit. But your implementation isn't built on top of
Contracts either, despite having similar features.
<sg15_at_[hidden]> wrote:
> On Tue, Oct 14, 2025 at 4:35 PM Gabriel Dos Reis via SG21 <sg21_at_[hidden]> wrote:
>>
>> The point is that hardened standard library implementations are being delivered right now, today, for supported language versions, without being phrased in term of P2900, by GCC, Clang, MSVC, etc.
>>
>> Any rephrasing in terms of P2900 should bring tangible benefits over what is available today. I see none.
>
>
> I don't think that is accurate. Libc++'s implementation of hardening is basically as close as possible to Contracts without actually using the language feature. We provide `enforce`, `quick_enforce`, `observe` and `ignore`, which can be selected using macros. We allow users to customize the handlers for `enforce` and `observe` in a way similar to what Contracts proposes. All of these decisions basically came from deployment experience and user feedback / feature requests (in particular observe, which we didn't have originally). IMO, that demonstrates a tangible benefit of wording hardening on top of Contracts, backed by libc++'s experience. Folks are free not to believe it, but it is historically and factually accurate that libc++ ended up where it is due to user demand and real world constraints. It's also the case that this has been deployed at a large scale and documented.
But that's still not phrased in terms of P2900. There's a difference
between how that thing works, and how it would work when phrased in
terms
of P2900 using actual contract assertions. You have there a
libc++-specific separation from any code using P2900, until you
possibly choose
to remove that separation. It turns out that separation is actually
useful, and in some cases, very useful.
And that's not a question of belief. There are actual reasons for such
a separation, and those have been observed (ha ha) in the wild.
> By the way, I'm not disputing that other standard libraries also provide useful hardening-like modes that are not built on top of Contracts. But that doesn't make what I said above untrue.
Sure, agreed, in spirit. But your implementation isn't built on top of
Contracts either, despite having similar features.
Received on 2025-10-14 21:53:17