Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #122969 > unrolled thread

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

Back to article view | Back to comp.lang.c++

Contents

  "Trip report: November 2025 ISO C++ standards meeting (Kona, USA)" Lynn McGuire <lynnmcguire5@gmail.com> - 2025-11-11 23:23 -0600
    Re: "Trip report: November 2025 ISO C++ standards meeting (Kona, USA)" Michael S <already5chosen@yahoo.com> - 2025-11-12 12:29 +0200
      Re: "Trip report: November 2025 ISO C++ standards meeting (Kona, USA)" Lynn McGuire <lynnmcguire5@gmail.com> - 2025-11-12 16:06 -0600
    Re: "Trip report: November 2025 ISO C++ standards meeting (Kona, USA)" Lynn McGuire <lynnmcguire5@gmail.com> - 2025-11-19 13:02 -0600
      Re: "Trip report: November 2025 ISO C++ standards meeting (Kona, USA)" David Brown <david.brown@hesbynett.no> - 2025-11-20 09:31 +0100

#122969 — "Trip report: November 2025 ISO C++ standards meeting (Kona, USA)"

"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 “must enforce this assertion”:"

"    We discovered two bugs, and adopted fixes for those at this 
meeting. One was paper P3878R1 “Standard library hardening should not 
use the ‘observe’ semantic” 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 “[basic.contract.eval] Make 
Contracts Reliably Non-Ignorable”by Darius Neațu, 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 “what syntax?” and “should violations 
call the violation handler or not?”, and bring a proposal to the March 
meeting."

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

Lynn

[toc] | [next] | [standalone]

#122973

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.

[toc] | [prev] | [next] | [standalone]

#122978

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

[toc] | [prev] | [next] | [standalone]

#123026

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 “must enforce this assertion”:"
> 
> "    We discovered two bugs, and adopted fixes for those at this 
> meeting. One was paper P3878R1 “Standard library hardening should not 
> use the ‘observe’ semantic” 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 “[basic.contract.eval] Make 
> Contracts Reliably Non-Ignorable”by Darius Neațu, 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 “what syntax?” and “should violations 
> call the violation handler or not?”, 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

[toc] | [prev] | [next] | [standalone]

#123029

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.  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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web