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

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

[@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".

[@ngideo]

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

[@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

[@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]

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())

[@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]

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

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

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

[@lorenzobolis5166]

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

[@ngideo]

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.

[@AnthonyDentinger]

Eh, sometimes you’ve been doing the same thing over and over. Sean Parent, for example, is a well-know presenter. Sometimes you just want to shake things up and try something different. At times, it works out and you do it more often, and at times not so much. This time, I feel like the format is not quite appropriate, but you might just have to try it out to see!

[@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

[@tshev]

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.