CppCon 2018: Titus Winters “Modern C++ Design (part 2 of 2)”

—
—
The old rules for C++API design are due for an update - we have made ad hoc changes to design principles in the standard library, but haven’t really written down the new ideas. Parameter passing and API design for free functions/member functions is due for a general update, particularly as a result of rvalue-references and reference qualification. How do we pass non-owning references? How do we sink a T? How do we express “maybe move” APIs? When do we want reference-qualified overload sets? What does an rvalue-reference qualified non-overloaded method mean? How do we express call once semantics?

For types, our consistency in producing Regular types has weakened in recent C++ releases with types like unique_ptr (move-only) and string_view (reference semantics). These classes of design that have shown themselves to be valuable, but certainly surprising at first. As we should not continue to extend the set of type designs arbitrarily, this is a good time to look at type design in the modern C++ era and narrow down the set of designs that are generally favored. This talk will focus on modern C++ design from small (choice of passing by value or reference) to large (Regular types, reference types, move-only types, etc). We will also introduce a taxonomy of type properties as a means to discuss known-good type design families.

We will also dive into the discussion of whether Regular design covers all good design, or whether there is more to the story.
—
Titus Winters, Google
C++ Codebase Cultivator

Titus Winters has spent the past 6 years working on Google's core C++ libraries. He's particularly interested in issues of large scale software engineer and codebase maintenance: how do we keep a codebase of over 100M lines of code consistent and flexible for the next decade? Along the way he has helped Google teams pioneer techniques to perform automated code transformations on a massive scale, and helps maintain the Google C++ Style Guide.
—
*--*
*-----*

[piotrarturklos]

This talk is awesome. In my opinion he really does talk about the most important guidelines for designing classes and structs in C++. This is not the kind of talk which says hand-wavy things you could reasonably argue with. The presented reasons for certain type design are fundamental in nature and must-know for anyone who wants to do serious C++, whether an API or an implementation. Those issues are: the checkable and external preconditions, thread-safety, thread-compatibility, regularity and its subproperties.

There was one point that I would add to the answer to the question about why 90% of classes are non-regular business logic. Particularly, I'd like to add an observation that even though 90% of classes are non-regular business logic, 99% of *objects* during runtime are of regular so-called vocabulary types. That's why it's important to take special care of those and to know all this stuff.

[garethbuxton]

But `span<>` is not designed to be passed by reference. A `span<>` is already a reference so why would you pass it by reference? Const spans have `const` data as in `span<const T> s;` and you can't do `span<T> copy = s;` because the compiler will not let you.

[YourCRTube]

Isn't the drama surround span blown out a bit too much, especially when it comes to const-ness? How is it different then an iterator or raw pointer for that matter? These are handle/view objects that have two const - one for the observed and one for the handle/view. If people make mistakes, this might be because they don't have enough experience yet; if even experienced with span programmers still make mistakes, then the api might be not good enough - may be different names for example? But the concept itself is useful, even if it is hard to describe in type-theory terms, and ultimately simple, as it is trivial to describe in real-word terms and by example.

[christopherhayden]

Anyone know if the committee considered separating span into two classes: one that is purely const and one that permits mutations, with the API suitably designed in each case to be as close to regular as possible? Something like const_span and mutable_span?

[antonyzhilin]

How many gurus does it take to make span<T> compare pointers instead of ranges?