159. C++23, WG21 February mailing, networking, safety, profiles, contracts

With Bjarne Stroustrup, Gianluca Delfino, and other colleagues.

Media

Video

Podcast

Powered by RedCircle

Feedback

Roi Barkan commented on the last episode:

  • Regarding the proposed shorthand concepts syntax: “I believe C++23 has a new meaning for auto{x} which is decay-copy of x, and thus it’s problematic to use it for “concepts in-place”
  • Regarding proposed safety profiles: “I wonder if there’s thought given to backward compatibility of profiles (e.g. if a piece of code complies with profile X in year 2023 can we allow the same code to be marked non-compliant with profile X in 2025 or 2029). As time goes by more profile checks can be implemented, and I personally think they should be encouraged regardless of compatibility.”
  • Regarding “erroneous behaviour”: “I think an example of errors of this nature are things referred to as IFNDR (ill formed, no diagnostics required). For example, I’m not sure but I think violations of the “one definition rule” can’t always be caught across translation units (by the linker) and thus considered as such an error. One difference from UB is that the compiler is required to compile UB code successfully, and allowed to fail on IFNDR”

We have C++23!

The sausage is made, the bread is baked. We now have C++23! With crossing all eyes and dotting all ts 😉 The best C++ ever, for all of ye!

Much of it is already implemented and released in compilers and can be used today, more will become available in the near future.

Some venting from the thread regarding networking, by Niall Douglas:

I presented a bare minimum viable vehicle for C++ 26 Networking at the Issaquah meeting, made viable mainly by dropping anything to do with async. It got killed. Committee wants async. Committee also wants several ponies and many unicorns in Networking. Committee wants it all, and currently doesn’t seem to care if that makes timely delivery impossible. I especially remember in the comments to my paper around the room there were clearly three separate factions, most with the opinion “either it’s my networking or I’m strongly against/over my dead body because the networking of the other tribe is the worst and would actively destroy my networking for various vague reasons” <…>

Looks like ASIO will be the C++ networking go-to solution for the foreseeable future.

See also:

Congratulations and huge thanks for everyone involved! A massive effort, especially with the pandemic still going on.

See also:

Issaqua trip reports

Inbal Levi on Reddit

2023-02 Issaquah ISO C++ Committee Trip Report — C++23 Is Done! 🎉

Herb Sutter

C++23 “Pandemic Edition” is complete

The previous standard, C++20, was completed in Prague in February 2020, a month before the pandemic lockdowns began. At that same meeting, we adopted and published our C++23 schedule… without realizing that the world was about to turn upside down in just a few weeks.

C++23’s main theme was “completing C++20” <…>

HackerNews thread

CppCast: Issaquah Trip Report and How the C++ Sausage Is Made

Safety Profiles: Type-and-resource Safe programming in ISO Standard C++

  • P2816R0 by Bjarne Stroustrup and Gabriel Dos Reis (slides)
  • Reddit

Niall Douglas writes:

After Bjarne’s presentation there was much outside of room chatter about his proposal. I won’t go into details, but suffice it to say that several leading committee members felt it has similar showstopper issues as Epochs had. If they succeed in persuading EWG of the same, those proposals in their current formulation are dead in the water.

A heated discussion follows, including this reply:

I was one of the people who opposed. To me, the question was ambiguous, paraphrasing:

Is the approach presented in the paper worth exploring?

It was not clear to me what do we mean by the “approach”. <…>

They go on to explain their objections.

My word, C++ developers are so emotional! Speaking of:

A Reaction to Dr. Stroustrup’s Recent Memory Safety Comments

Article by Jimmy Hartzell

To be honest, I was disappointed. As a current die-hard Rustacean and former die-hard C++ programmer, I have thought (and blogged) quite a bit about the topic of Rust vs C++. Unfortunately, I feel that in spite of the exhortation in his title to “think seriously about safety,” Dr. Stroustrup was not in fact thinking seriously himself.

Oh boy. The article contains so much venting it could fill a surveillance air balloon. There are a few straw-man arguments (including a jab at Bjarne for allegedly using a straw-man argument) and a lot of pent-up emotion. An entire section is dedicated to defending the use of “C/C++”.

The tone of the article is quite condescending, that of the “I know better” variety, and honestly makes for an unpleasant reading. (Maybe it’s just me.)

I mean, you are a fan of Rust and don’t like C++, I get it. Just keep using Rust, nobody is taking it away from you. For Rust to become popular, C++ doesn’t have to disappear. But no, it’s a zero-sum game for the author, who cannot stop himself explaining to Bjarne and the rest of us the errors of our ways.

The author’s Twitter profile says:

Systems programmer in Rust, Haskell fan, had a bitter break-up with C++ and never looked back.

For someone who “never looked back” he seems obsessed with his “ex”.

To sum it up: I read these sorts of articles so that you don’t have to. Don’t waste your time on this one.

Rust Safety Is Not Superior To C++, Bjarne Stroustrup Says

Slashdot

Something I thought I’d never say, but a pretty sane discussion on Slashdot.

The Evil Atheist writes:

You don’t need to change the C++ model. You can write static analysis tools to do the same thing, which is exactly what he talks about even in the summary. You literally can write a borrow checker as a tool, rather than make it part of a compiler.

The Core Standard Guideline support library is one of those things that, coupled with the newer language capabilities, is being used to do stuff like this.

See also

RFC: C++ Buffer Hardening

LLVM, by Louis Dionne (Apple)

We plan to implement a hardened mode of libc++ in which several cases of undefined behavior are caught and turned into assertion failures instead.

Towards the next generation of XNU memory safety: kalloc_type

Apple

About Safety, Security and yes, C++ and Rust

Article by David Teller

I’ve seen many misunderstandings about what safety means in programming and how programming languages can implement, help or hinder safety.

A very sane and entertaining reaction to the NSA and Consumer Reports documents regarding “C/C++” (ye gods) and the resulting Reddit threads.

Your favorite language is not perfectly safe. It is not perfectly secure. It is not even safer and more secure than most other languages for all teams of developers, all domains, all threat models.

If you’re reading these lines and must remember only one thing, please, fellow developers in $(YOUR FAVORITE LANGUAGE), stop trolling developers with different experience. Chances are that they are perfectly right to use these tools that you despise. Even if they’re not, trolling is not constructive.

He ends with this:

Use whichever language makes sense for your goal, specs and threat model. There are many use cases in which I will be using Rust if I have a choice. But I’ll happily use a different tool if it feels appropriate.

Very well put.

WG21 February mailing

Paper: Introduction of std::hive to the standard library

P0447R21

C++26?

Paper: A Big Decimal Type

P2159R1

This paper proposes an exact decimal type that can be used as either a fixed point type or a floating point type with an implementation-defined maximum precision.

Paper: Towards memory safety in C++

P2771R0 by Thomas Neumann

Lifetime annotations for function parameters combined with a general opt-in safety annotation.

Paper: Not halting the program after detected contract violation

P2784R0 by Andrzej Krzemieński

This paper explores the possibility of not stopping the program after a contract violation has been detected at run-time. This is a feature to be added to the contract support framework.

Proposed solutions:

  • Exceptions (but what if we have a throwing condition check in a destructor? — how about don’t do that?)
  • Aborting the component (!)

As a potential solution to the above problem we propose a mechanism that is harsher than stack unwinding, but softer than std::abort(). In fact we are proposing a stricter and simpler version of the setjmp/longjmp mechanism

We did manage to avoid throwing from destructors so far…

See also: Unconditional termination is a serious problem, by Bjarne Stroustrup.

Paper: do expressions

P2806R0 by Bruno Cardoso Lopes, Zach Laine, Michael Park, Barry Revzin

1int x = do { do return 42; };

This solves a problem of specifying expressions in pattern matching.

Reddit thread on do expressions.

Book: Applied Modern C++, by Christopher Di Bella

Book: A Complete Guide to Standard C++ Algorithms, by Šimon Tóth

Mastodon

Shantini, an Apple software engineer, says:

People will always see your software as the bugs you write, so make sure you write really epic and memorable bugs

Robyn Syl writes:

Roses are red, my code is a disaster
git push --force origin master