On Sun, 16 Aug 2026 at 02:42, Peter Bindels via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> One of the papers says it's not implemented - I don't understand how they cannot see GCC16 existing since March, in a paper written in August. It makes you doubt the other statements in the paper, even though there are some valid concerns in there.

Is there an implementation that works on Windows?

> I have also looked at what constification would mean for an actual codebase in P3268, and tried it in my personal codebase of about 50kloc, where it found one ICE in both the GCC and Clang implementations (Clang is unmerged), and about 10 bugs in my code. Not a widespread rollout, true, but experience nevertheless. That specific ICE was fixed this week for a future release.

Constification causes all sorts of issues for static analysis. Such
issues are not limited to having compute equivalent Value Numbers for
different
expressions that sprung up because of constification. They are issues
that simply cause static analysis to have to do More Work doing the
unwrapping
of the constifying-wrappers.

>> As an experiment, I have implemented contract-like checks in terms of compile_assert().
>> https://github.com/jonnygrant/compile_assert/blob/main/testsuite/main28_a.cpp
> compile_assert, if I understand it correctly, is identical to contracts in P2900 when set up to have a C++ library that does not implement its violation handler function. Your program will link if and only if it could be proven during compilation. That already works like that - in fact, I at first didn't notice I had forgotten to switch over to my experimental libc++ until it failed to link after adding a few contracts. The first few in the places they were called were always true and didn't emit a symbol to link to in the first place.

I don't quite follow. P2900 does nothing like that compile_assert.