On 18/02/2025 23:50, Paavo Helde wrote:
On 18.02.2025 09:13, Lynn McGuire wrote:
"Trip report: February 2025 ISO C++ standards meeting (Hagenberg,
Austria" by Herb Sutter
https://herbsutter.com/2025/02/17/trip-report-february-2025-iso-c-
standards-meeting-hagenberg-austria/
"This time, the committee adopted the next set of features for C++26,
and made significant progress on other features that are now expected
to be complete in time for C+26.
In addition to features already approved for C++26 at previous
meetings, at this meeting three major features made strong progress.
In the core language:
P2900 Contracts was adopted for C++26
P2786 Trivial Relocatability was adopted for C++26
P1967 #embed was adopted for C++26
In the standard library:
P3471 Standard Library Hardening (which is also the first use of
contracts) was adopted for C++26
P0447 std::hive was adopted for C++26
Other noteworthy progress:
P2996 Reflection is almost done its specification wording review
aiming for C++26, and is expected to come up for vote for inclusion in
C++26 at the June meeting"
I guess that I will have to spend some time on figuring out what
Contracts is.
https://timur.audio/contracts_explained_in_5_mins
Thanks for posting this, appreciated!
I looked at the contracts proposal briefly. The basic idea seems simple,
just add formalized pre-, post- and in-between condition checks to C++ functions. Alas, it appears the result provides a lot of really good
stuff for adding to the obscure C++ quizzes, and valuable contributions
to obfuscated C++ contests ;-)
In more detail, the contracts feature has subtle non-trivial
interactions with top-level const, lambda captures, coroutines, virtual functions, compiler optimizations, array decay, auto, etc. There are irregularities in irregularities. This is quite an achievement for a
feature whose main design principle is to have no effect at all (in
correct programs).
Understanding this kind of thing, and how various aspects of C++
interact, is a big part of why it takes so long to get features like
contracts into the language. It is, I think, an inevitable consequence
of an evolving language that maintains strong backwards compatibility.
The only way out of this is a blank slate - take the features that C++
has now, and might have in the future, add the goals of the language,
and then try to form a new language that incorporates these from the
start so that it is much easier to get a consistent whole which
minimises these complications. For example, if the language had had a distinction between "pure functions" (no side-effects or observable
behaviour) and "procedures" (where you can have side-effects and
observable behaviour) from its foundations, then you could probably
eliminate most of the complications of contracts by restricting them to
using only pure functions.
Until such a new language is created (Carbon and Cpp2 are perhaps the
nearest ideas at the moment), all we can do is use the features we like,
and avoid those we dislike.
Personally, I think contracts are a major step forward for the language,
even with their complications. And like most such things, ordinary
programmers can generally ignore a fair proportion of these
complications. If mixing coroutines and contracts can lead to strange
effects, then the answer is extremely simple for most people - don't mix coroutines and contracts. People writing re-usable libraries will have
to deal with this sort of thing, but most programmers will be able to
avoid them.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)