Date: Wed, 11 Mar 2020 16:01:23 -0600
On Mon, Mar 9, 2020 at 5:14 AM Bryce Adelstein Lelbach aka wash via Modules
<modules_at_[hidden]> 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.
<modules_at_[hidden]> 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.
Received on 2020-03-11 17:04:22