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
SFFNASA
1744153120

Not consensus

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

SFFNASA
3941142314

That looks consensus-y

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

SFFNASA
9835602

Consensus

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

SFFNASA
4126391313

Consensus

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

SFFNASA
33124370

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.
To come back on topic, giving ownership of standard entities to modules would be a "big" break and wg21 voted against "big"

 
_______________________________________________
SG15 mailing list
SG15@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15