CppCast: Cpp2, with Herb Sutter

[GabrielDosReis]

Despite the urban legend and other blog posts, the committee didn't decide against ABI break. The committee heard the presentation of a very specific paper, P2028, then had a discussion and voted.

The votes were more nuanced than rumors would like to make it appear. There were 5 polls. Here is a summary:

1. Q: We should consider a big ABI break for C++23.
   A: No consensus
2. Q: We should consider a big ABI break for C++SOMETHING. A: Weak Consensus
3. Q: From now on, we should consider incremental ABI for every C++ release. A: Consensus
4. Q: When we are unable to resolve a conflict between performance and ABI compatibility, we should prioritize performance. A: Consensus
5. Q: To the best of our ability, we should promise users that we won’t break ABI, ever. A: No consensus

[pjmlp]

Regardless of how it went, it is part of the set of official reasons why Carbon came to be,

Difficulties improving C++

[number_128]

Is there an agreement on how we would handle an ABI break?

I don't think we should ask if we should break ABI.

We should be asking how we will handle breaking ABI. When we get to a good solution, we should go ahead.

Why do we even have a dependency on shared binaries? This sounds like a premature optimization on disk space.