On Mon, 4 Sept 2023 at 20:59, Brian Bi <bbi5291_at_[hidden]> wrote:
>> Appears? Based on what? I could quantify that ABI break cost to a
>> dollar precision for various companies if I really had to (because
>> we've done it accidentally, by packaging with a platform that had a
>> newer GLIBC that results in packages that don't work on systems
>> with an older GLIBC, due to an.. *drumroll* ..ABI incompatibility).
>> What is this disagreeing appearance based on? Hot air?
>
>
> Is the particular ABI incompatibility that you have mentioned here one that could be caused by any decision WG21 could possibly make? glibc is not written in C++.

Yes, thanks, I know that glibc is not written in C++. WG21 could make
an ABI break where the cost is much worse than that, and they can
also make an ABI break where the cost is identical to that - by
forcing libstdc++ to break ABI. I mention that example because it's
just
one way for an OS brand $x version $foo to be incompatible with
versions older than $foo, or of brand that is not $x, because they're
essentially the same as "older than $foo".

> Nevertheless, I'm not making the claim that no one ever accurately estimates the costs of any ABI-breaking change. There is no one "cost of breaking ABI"; the cost depends on the particular change in question. Those particular costs typically never receive a numerical estimate.
>
> Here's what usually happens in the C++ standardization process: First, someone gets an idea for a proposal. At some point between the time when they first get that idea and when the proposal gets polled in EWG, someone points out that adopting the proposal would require an ABI break. Most of the time, no one ever puts forth an estimate of the dollar cost of that particular ABI break. Instead, the author simply realizes that the proposal has no chance of getting accepted in the current form. If the ABI break is pointed out while the paper is being discussed in EWG, the result is that the room simply agrees not to poll that particular version of that proposal. The proposal then dies unless the author can find a way to avoid the ABI break. No one estimates the dollar cost of not adopting the proposal, either. Therefore, a numerical comparison is not made between the two costs. Instead, a lot of people simply assume that the former cost outweighs the latter, which is why the proposal is not accepted. Any appearance that one cost outweighs the other is therefore backed by exactly as much evidence as any appearance of the reverse.

Well, thanks for reporting that - that report doesn't match my
experiences of what's typical in EWG, or LEWG. Where it does match is
that we indeed
do not usually talk about a dollar cost either way, although sometimes
we have, at least as relative figures (meaning estimates of the
increased
cost of testing and packaging), when someone has insisted that we do.

I don't see how that leads to an appearance that the cost of ABI
breaks is overestimated, though.

I suppose I should also point out the fun part that an existing
shipping product in the hands of a customer incurs no cost if a system
library
is updated and no ABI break occurs, but there certainly is a cost if
an ABI break does occur.

I should also point out the same thing as Jason did. It's not just
about the comparison of numeric costs, it's about on whom the cost is
inflicted
and what the likelihood of that party being able to reasonably bear
that cost is.

Any analyses I've attempted at quantifying that has ABI breaks
resulting as strictly inferior to keeping ABIs stable.

And I still don't see how that appears overestimated, but then again..
..I don't really care. If it "appears" overestimated with zero facts
backing
up that appearance, whereas the estimates are based on fairly many
facts, and also contain some amounts of guesstimate noise, I still
know which
indication to pick, it's easy.