On Wed, 11 Mar 2020, 22:08 Corentin Jabot via Lib-Ext, <
lib-ext_at_[hidden]> wrote:

>
>
> On Wed, 11 Mar 2020 at 23:01, David Stone via SG15 <sg15_at_[hidden]>
> wrote:
>
>> 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.
>>
>
> For impacted users, all abi breaks are abi breaks,
>

That's a "no true scotsman" fallacy. If a break doesn't hurt, it isn't a
*real* break.




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

Changing the return type of emplace was a small break. Changing std::string
parameters from iterator to const_iterator was a small break. Changing the
return type of std::map::insert from void was a small break.

The point is, small breaks are possible, and the impact can be mitigated so
that it isn't necessary to cause a link-time failure.