Better Code: Exploring Validity in C++ - David Sankel - CppCon 2023

---

Better Code: Exploring Validity in C++ - David Sankel - CppCon 2023

Most developers have at least some notion of the meaning of object, state, invariant, value, and invalid. On the other hand, it can be surprisingly
difficult to precisely define these words in a way that matches both
intuition and common usage. This difficulty has even led to divergence within the C++ standard library!

This talk is a journey of discovery where we not only find satisfactory
definitions, but identify practical, good coding practices along the way.
At the end of this talk you'll be able to name implicit contracts,
understand the deep connection between move semantics and exception safety, and, in general, have a greater appreciation for the meaning of the programs we write every day.
---

David Sankel

David Sankel is a Principal Scientist at Adobe and an active member of the C++ Standardization Committee. His experience spans microservice architectures, CAD/CAM, computer graphics, visual programming languages, web applications, computer vision, and cryptography. He is a frequent speaker at C++ conferences and specializes in large-scale software engineering and advanced C++ topics. David’s interests include dependently typed languages, semantic domains, EDSLs, and functional programming. He is the project editor of the C++ Reflection TS, Executive Director of the Boost Foundation, and an author of several C++ proposals including pattern matching and language variants.
---

---

#cppcon #cppprogramming #cpp

[lorenzobolis]

Definitely one of the best 'better code' talks, just great work all around from the STLab!

[mrlithium]

Alternate title: Existentialism of Objects

[aharrison]

Really fascinating talk. I like the idea of discardability, as it clearly allows for more efficient implementations in some cases. But I wonder if its definition needs to be slightly modified.

It's stated in the talk that an object in a meaningless/discardable state should *only* be destroyed or assigned to,  and that moving from an object will leave it in a discardable state. Currently the standard requires that when types in the standard library are moved-from they will be left in a "valid but unspecified state.". That's obviously a stronger requirement than mere discardability. In particular it allows for a moved-from object to be moved-from *again* (although it will of course leave the moved-to object in a valid but unspecified state too). In fact that's a necessary property in order to ensure that for some meaningful object 'x', that std::swap(x, x) is well-defined.

There are three operations in std::swap(x, x), and for the operation to be well defined, none of them should involve UB. Assuming we were to adopt a model where moved-from objects are only discardable:
[1] T temp = std::move(x); // Leaves x in a moved-from state (i.e. it is now 'discardable')
[2] x = std::move(x); // We need this to not be UB. It can leave x in a discardable state, though.
[3] x = std::move(temp); // This restores the meaningfulness of x


For this to work, we need the self-move-assignment in [2] to not be UB. That is the only requirement. It's fine for it to leave 'x' in a meaningless state.

So my question is: Should the definition of discardability be updated to allow an object to be destroyed, assigned-to or *moved-from*?

[Dth]

For the question at 53:00 regarding a function named "get_value()", the function returns an object that has a value, or essence. It does not return a "value" as such, and that's the distinction.
Also, I think having "value" and "essence" as different terms can be useful; for the rational number case study, 1/2 and 2/4 have the same essence, but may be considered to be different "values" (albeit representing the same thing) to some programmers and so introducing a new, more specific term helps clear any confusion.

[AlfredoCorrea]

28:18 of course there is a way for unique_ptr, do not provide .get(). force all raw access through .release() and reinstate (e.g. .reset) later if necessary.

[NonTwinBrothers]

That adobe ampersand always brings me life

[__hannibaalbarca__]

I m looking for job as C++ developer; my background is mathematician

[alskidan]

What if an object can be valid or not with respect to multiple functions? I can't buy the argument that `is_readable` will be better than `is_valid` in such case. For example, a file handle may be invalid with respect to a bunch of operations: close, read, seek, etc.

Arguably, the most common case is for objects to be invalid with respect to different contexts (functions) rather than one context.

[Voy]

50 minutes for 5 min of obvious content

[alskidan]

One more thing, secure_hash_map is kind of a bad example. It’s not meant to be understandable, it’s meant to be secure. The more obfuscated a thing is, the more secure 😂