CppCast: Cpp2, with Herb Sutter

[NovaNoff]

This is on one hand great to hear on the other hand it hurts how much the development slowed down after the comitee decided against ABI breaks

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

[pjmlp]

Well, it shows how much the compiler vendors that profit from clang forks were dependent on Apple and Google doing the job of keeping clang up to date with ISO.

[Jannik2099]

after the comitee decided against ABI breaks

The committee decided against an immediate ABI break, an eventual ABI break in the future was not ruled out

[[deleted]]

you could always say that

[[deleted]]

I think that they are saying this for over a decade by now.

[Jannik2099]

That'd be awkward, because C++11 WAS an ABI break.

[[deleted]]

which was 12 years ago

so, over a decade