Better Code: Contracts in C++ - Sean Parent & Dave Abrahams - CppCon 2023

cppcon.org/
---
Better Code: Contracts in C++ - Sean Parent & Dave Abrahams - CppCon 2023
github.com/CppCon/CppCon2023
Are you confident that the code you write, and the changes you make, are correct? What does “correct” even mean? How do we know the code we write today won’t become a long-term liability? These persistent questions can be enough to suck all the fun out of programming, but it doesn’t have to be that way. In this talk, we’ll look at the connective tissue of good code and show how to keep it strong and supple. There is no need to wait for language features to start using contracts. We’ll suggest replacing code reviews with something better and charting the path to a more hopeful future of software.
---
Dave Abrahams
Dave Abrahams is a founding contributor of the Boost C++ Libraries project and the founder of the first annual C++ conference, BoostCon/C++Now. He is a contributor to the C++ standard, and was a principal designer of the Swift programming language. He recently spent seven years at Apple, culminating in the creation of the declarative SwiftUI framework, worked at Google on the Swift for TensorFlow project and, briefly, on the Carbon language, and is now a principal scientist at Adobe's Software Technology Lab.
Sean Parent
Sean Parent is a senior principal scientist and software architect managing Adobe's Software Technology Lab. Sean first joined Adobe in 1993 working on Photoshop and is one of the creators of Photoshop Mobile, Lightroom Mobile, and Lightroom Web. In 2009 Sean spent a year at Google working on Chrome OS before returning to Adobe. From 1988 through 1993 Sean worked at Apple, where he was part of the system software team that developed the technologies allowing Apple’s successful transition to PowerPC.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
CZcams Channel Managed by Digital Medium Ltd: events.digital-medium.co.uk
---
Registration for CppCon: cppcon.org/registration/
#cppcon #cppprogramming #cpp

[@ABaumstumpf]

We have found some code that really DID abuse exceptions for control-flow .....
In a loop a few conditions were checked, some data manipulated, and at one point if the condition was true - somebody came up with the idea of throwing an exception and catching it at the end of the loop to skip the rest of the loop-body.... an exception-based "continue".

[@AlfredoCorrea]

2:10 little known fact: Abrahams father was a well known condensed matter physicist. Praise to Dave for recognizing that code is ultimately built on physics.

[@niklkelbon3662]

Thank you for the video
Non trivial contracts and invariants are really very hard to create and maintain, and video explains it well
Also, hard contracts have no optimization potencial (compiler will not understand what equal(b, e, old.b) really means) and may have side effects (so checking / not checking may have observable effects)
My approach:
1. allow only pure expressions as contracts, add [[pure]] for functions into language
2. add 'invalidates_iterators | references _if', `changes_only(a, b, c)` as contracts, also `.foo is unreachable|reachable`, for example after constructing .unlock is unreachable, after lock it is reachable.
3. add constracts for all standard primitives in the STL, like string, vector, mutex, algorithms etc
For optimizations checking should be before and after each public function call (but there are big questions about calling public api functions from constructor or from functions, which constructor uses)
There are two tasks for contracts, optimizations and static/dynamic analisys, i hope my approach will serve both

[@_engid]

Babe, wake up. A new Better Code talk just dropped!

[@lorenzobolis5166]

Great talk, but I wish they didn't just (badly) read a script

[@_engid]

It feels like watching an infomercial :D

[@Eyalkamitchi1]

They're not actors lol

[@fareloz]

​@@Eyalkamitchi1then why they act?

[@simplyshow]

I am guessing that they are targeting a different type of audience here. It is apparent to me that they have something useful to say and have invested a lot of effort into their preparing the material. But either they did not put in enough efforts to actual presentation or they are not exactly good actors! I prefer teachers to actors when I am learning something! They don't seem to be targeting my type of learners.

[@aniketbisht2823]

The paper for the upcoming contracts proposal mentions that contracts assertions should always specify a subset of the "plain-language contract" i.e the documentation. The paper also notes : "Not all parts of a contract can be specified via contract assertions, and of those who can, some cannot be checked at runtime without violating the complexity guarantees of the function, without additional instrumentation or at all."

[@Roibarkan]

10:50 notice how Dave treats vector as an advantage 🙃

[@alskidan]

Great talk. Reminded me of a play at my daughters’ school. 😂 But in all seriousness: contracts are documentation.

[@embeddor3023]

compiler-checked documentation that is.

[@Roibarkan]

33:13 I guess the added line in slide 107 was meant to be added before the “throw” (potentially instead of the calls to clear())

[@aniketbisht2823]

12:31 In the side transition : changing the old assert technique to proposed contract syntax, the pre condition is wrong. size() should be greater than zero.

[@AlfredoCorrea]

36:09 minimal guarantee is analogous to what the theory of Partially Formed values proposes. I am surprised to find it here in a different context: it seems that this idea of stopping obsessing about holding invariants heroically under all circumstances (including after errors, after default construction, and after the move) is catching on. If I understand Sean-verse correctly, after an error, all (some?) the objects that participate in a try block can be considered generically in a moved-from just-destructible state. But I don't see the complete pattern, though; should they not be used at all outside the try-catch block? How does it work?

[@vaughncato]

At 33:40, Sean also mentions that it is specifically related to objects under mutation in the try block.

[@AlfredoCorrea]

@@vaughncato Yes. Good. I guess mutations without preconditions are excluded. Also, I guess for specific catch arguments the exact rules can become more subtle.

[@frantisekdobrota5742]

5110 removes the last element - there is a lot unspecified behaviour in that sentence, where is the element removed to? What happens to the slot where the element resided? Is the element destroyed? All of that is not specified in "removing an element", programming c++ for 15 years I dont kid myself that there is a lot of guesswork included and we use jargon and rely on implied stuff in comments everywhere

[@TShevProject]

Human language is not precise, which allows you to explain things without mentioning the details and relying on other people's interpretations.

[@rapopescu]

incredibly disappointing, in content and presentation, especially considering this comes from Sean Parent.