C++Now 2018: Titus Winters “Modern C++ API Design: From Rvalue-References to Type Design”

that's an ugly lectern

To John Lakos's question about whether we should assume alias safety or not by default: In my opinion not being alias safe violates the principle of least surprise. That pretty much completely answers the question for me. On the other hand I think the restrict keyword is ass backward: you should have to explicitly annotate things when you expect them to alias (but what is the syntax for that supposed to look like?)

Interesting, but yet more proof that C++ has gotten completely out of control.

On thread safety, I would take the approach that any class that isn't explicitly documented as thread safe shouldn't be accessed at all from multiple threads without sync. That's just the sane, safe scenario, and you won't get bitten later when something gets changed behind your back. You should already be very much minimizing contact points between threads anyway, so it's not like it should make much difference.

There are times when you can "magically guarantee" that your program will have only one thread. For the last 4+ years, all the code my team has written that should be parallel has also been distributed over a cluster. We have not needed threads. However, caching has remained very useful. So we have lots of places in our code-base where there is a mutable `m_cache` variable. It would be expensive and unnecessary to lock a mutex at every one of the billions of accesses.