From Newsgroup: comp.lang.c++

"Trip report: November 2025 ISO C++ standards meeting (Kona, USA)" by
Herb Sutter

https://herbsutter.com/2025/11/10/trip-report-november-2025-iso-c-standards-meeting-kona-usa/

"On Saturday, the ISO C++ committee completed the first of two final fit-and-finish meetings for C++26, in our meeting in Kona, USA. What we
have in the C++26 working draft represents exactly the set of features
we have consensus on so far; the goal of these last two meetings is to
fix bugs and otherwise increase consensus for the C++26 standard. We are
well on track to complete our work on C++26 and set it in stone at our
next meeting in March 2026."

"For contracts (pre, post, contract_assert), we spent most of Monday and Tuesday reviewing feedback. The strong consensus was to keep contracts
in C++26, but to make two important bug fixes and pursue a way to
specify rCLmust enforce this assertionrCY:"

" We discovered two bugs, and adopted fixes for those at this
meeting. One was paper P3878R1 rCLStandard library hardening should not
use the rCyobserverCO semanticrCY by Ville Voutilainen, Jonathan Wakely, John Spicer, and Stephan T. Lavavej.
For the next meeting in March, we are also pursuing something like
the first proposed solution in P3911R0 rCL[basic.contract.eval] Make
Contracts Reliably Non-IgnorablerCYby Darius Nea+cu, Andrei Alexandrescu, Lucian Radu Teodorescu, and Radu Nichita (though not necessarily with
that particular syntax). The idea is to add an option to express in
source code that a pre/post/contract_assert must be enforced, which some
view as a necessary option in the initial version of contracts. A group
of interested persons will work on that design over the winter,
including to answer questions like rCLwhat syntax?rCY and rCLshould violations call the violation handler or not?rCY, and bring a proposal to the March meeting."

One of these days, I will figure out what contracts are again.

Lynn

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Tue, 11 Nov 2025 23:23:32 -0600
Lynn McGuire <lynnmcguire5@gmail.com> wrote:

One of these days, I will figure out what contracts are again.

Lynn

I don't believe you.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 11/12/2025 4:29 AM, Michael S wrote:

On Tue, 11 Nov 2025 23:23:32 -0600
Lynn McGuire <lynnmcguire5@gmail.com> wrote:

One of these days, I will figure out what contracts are again.

Lynn

I don't believe you.

I did not say that I was in a hurry. I am an old dog, teaching me new
tricks does not work well.

Lynn

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 11/11/2025 11:23 PM, Lynn McGuire wrote:

"Trip report: November 2025 ISO C++ standards meeting (Kona, USA)" by
Herb Sutter

https://herbsutter.com/2025/11/10/trip-report-november-2025-iso-c- standards-meeting-kona-usa/

"On Saturday, the ISO C++ committee completed the first of two final fit-and-finish meetings for C++26, in our meeting in Kona, USA. What we
have in the C++26 working draft represents exactly the set of features
we have consensus on so far; the goal of these last two meetings is to
fix bugs and otherwise increase consensus for the C++26 standard. We are well on track to complete our work on C++26 and set it in stone at our
next meeting in March 2026."

"For contracts (pre, post, contract_assert), we spent most of Monday and Tuesday reviewing feedback. The strong consensus was to keep contracts
in C++26, but to make two important bug fixes and pursue a way to
specify rCLmust enforce this assertionrCY:"

"-a-a-a We discovered two bugs, and adopted fixes for those at this
meeting. One was paper P3878R1 rCLStandard library hardening should not
use the rCyobserverCO semanticrCY by Ville Voutilainen, Jonathan Wakely, John
Spicer, and Stephan T. Lavavej.
-a-a-a For the next meeting in March, we are also pursuing something like the first proposed solution in P3911R0 rCL[basic.contract.eval] Make Contracts Reliably Non-IgnorablerCYby Darius Nea+cu, Andrei Alexandrescu, Lucian Radu Teodorescu, and Radu Nichita (though not necessarily with
that particular syntax). The idea is to add an option to express in
source code that a pre/post/contract_assert must be enforced, which some view as a necessary option in the initial version of contracts. A group
of interested persons will work on that design over the winter,
including to answer questions like rCLwhat syntax?rCY and rCLshould violations
call the violation handler or not?rCY, and bring a proposal to the March meeting."

One of these days, I will figure out what contracts are again.

Lynn

https://en.cppreference.com/w/cpp/language/contracts.html

https://www.reddit.com/r/cpp/comments/1idumqe/contracts_for_c_explained_in_5_minutes/

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2900r14.pdf

Looks complicated. And is another version of assert.

Lynn

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 19/11/2025 20:02, Lynn McGuire wrote:

On 11/11/2025 11:23 PM, Lynn McGuire wrote:

One of these days, I will figure out what contracts are again.

Lynn

https://en.cppreference.com/w/cpp/language/contracts.html

https://www.reddit.com/r/cpp/comments/1idumqe/contracts_for_c_explained_in_5_minutes/

The actual article, rather than a forum of chatter about it:

<https://timur.audio/contracts_explained_in_5_mins>

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2900r14.pdf

Looks complicated.-a And is another version of assert.

Lynn

Contracts are about giving specifications to parts of code in a way that
is (or should be!) clear and consistent.

Instead of writing this :

// Pass this function a value "x", and it will calculate
// the value "y" so that y*y <= x < (y+1)*(y+1)
// Trying to find the square root of a negative number is UB.
int int_square_root(int x);

You can soon write (assuming I've got the syntax correct - C++26 is not
yet finished) :

int int_square_root(int x)
pre(x >= 0)
post(y : y * y <= x)
post(y : x < (y + 1) * (y + 1));


Now your specifications are not just comments that can be misunderstood
by the programmer, ignored by the compiler, and inconsistent with the implementation code. They are part of the code. Depending on compiler
flags or pragmas (I think this part is up to the implementation), the contracts can be ignored, checked with debug messages, trigger a handler
on failure, or cause program abort on failure. (I'd expect toolchains
to add debugger breakpoint on failure too.) And compilers will be able
to optimise on the assumption that the contracts are "true" if they pass
(or are ignored). And of course compilers can always do extra
zero-runtime checks when dealing with values known at compile time.

Yes, the contracts are somewhat like assert(). But a key feature is
that they are in the right place. Putting "assert(x >= 0)" at the start
of your "int_square_root" implementation means your perfectly correct
and debugged "int_square_root" function is bigger and slower due to
debug code, and when the assertion is triggered, your code aborts inside
the working function. Oh, and your function is no longer "pure" or
constepxr. With the "pre" contract, the check is in the right place -
at the calling site, where you might have an invalid value.

Yes, contract_assert() is a lot like assert(). But it is part of the
language rather than a macro, and that gives the language and tools a
lot more flexibility, such as how it interacts with compile-time
evaluation code, reflection, or toolchain-specific stuff.




--- Synchronet 3.21a-Linux NewsLink 1.2