On Wed, 11 Mar 2020 at 23:01, David Stone via SG15 <sg15@lists.isocpp.org> wrote:

On Mon, Mar 9, 2020 at 5:14 AM Bryce Adelstein Lelbach aka wash via Modules <modules@lists.isocpp.org> wrote:

As I recall, we did not have consensus to evolve the ABI at Prague.

As a reminder, these were the polls: 

 1. We should consider a big ABI break for C++23

SF	F	N	A	SA
17	44	15	31	20

Not consensus

2. We should consider a big ABI break for C++SOMETHING

SF	F	N	A	SA
39	41	14	23	14

That looks consensus-y

3. From now on, we should consider incremental ABI for every C++ release

SF	F	N	A	SA
98	35	6	0	2

Consensus

4. When we are unable to resolve a conflict between performance and ABI compatibility, we should prioritize performance

SF	F	N	A	SA
41	26	39	13	13

Consensus

5. To the best of our ability, we should promise users that we won’t break ABI, ever.

SF	F	N	A	SA
3	3	12	43	70

No consensus

My understanding of these results is that there is no plan to intentionally break everything that could potentially benefit from it in C++23, but we did not vote to reject any proposal targeted at C++23 that would break ABI. I think this is an important but subtle difference. There is a strong argument in favor of the "big ABI break" approach, which is to make it more obvious to users that they cannot mix modes, but the results of the first and second polls together say that we want to do that at some point, but 3 years is insufficient time for anything that large.

Importantly, we never took a vote saying we do not want to break ABI at all in C++23, and we specifically took a vote that found we do plan on breaking ABI as a general concept.

For impacted users, all abi breaks are abi breaks,

there are no big or or small, the only difference is that we know how to make big breaks link-time diagnosable.