Date: Sat, 13 Jul 2024 06:51:46 -0700
On Saturday 13 July 2024 02:48:52 GMT-7 Hans via Std-Proposals wrote:
> > I am looking at that and I addressed in my paragraph: the design was that
> > libstdc++ would keep ABI and strictly speaking, it did. The issue was
>
> I disagree with that. No 'design' was involved in the stability of
> libstdc++. Instead its developers realised, at some point, that they
> were no longer able to change anything because too many people relied on
> their existing ABI. Calling that 'design' is like falling of a ladder
> and then shouting "I meant to do that!"
You're disagreeing with facts.
The developers of libstdc++-v3, which produces libstdc++.so.6, clearly knew
back in the early 2000s the need about ABI stability. It's the third
implementation of libstdc++ and it's the sixth binary-incompatible release of
those libraries. They had the means to rev up when they broke ABI and they had
already used it before.
The most recent change was libstdc++.so.5 to 6, which happened in GCC 3.4. I
don't remember for sure that there were no changes to the ABI implementation
in the compiler from 3.3 to 3.4, but from what vague memory I have of the
event, the actual compiler-generated ABI (mangling scheme, etc.) was stable in
that release and backwards compatible with 3.3.
So, no, the need for ABI stability was well understood back then and was part
of the design of current libstdc++ today. And even if it wasn't, libc++ would
have no such excuse, because it's much newer and had the benefit of experience.
> My design removes the issue of ABI stability being poorly explained to
> library developers. It formalizes what is, and what isn't stable. It is
> precisely the answer to the problem you formulated here.
This is completely irrelevant.
First, you don't need to explain ABI or not to Standard Library developers.
They already know it. The only thing you're changing is that some API dictated
by the standard would be marked "subject to change" but as I argued in my
other email, we already have such a mechanism in the form of TRs and TSes.
Second, you're not explaining how doing anything helps the implementors write
more stable ABI. Saying "std::stable::string is stable" does not make it
stable. I'll repeat my question: given the implementors of the original
std::string thought it was stable, how does your proposal guide them to not
making the same mistake in std::stable::string?
> Sure, why not. FOR THE PURPOSE OF EXPOSITION, instead of implementing a
> stable class myself and defining its ABI, I'll borrow the existing class
> from the standard library. THIS IS NOT HOW IT WOULD WORK IN THE REAL
> WORLD, but it is close enough that it will suffice FOR AN EXAMPLE.
You misunderstood my question.
I don't want to see how it would be used by user code. I want to see how it
would be implemented, so we can judge performance limitations and how the new
design is (or fails to be) more conducive to keeping a long-term ABI.
> Are you actually serious about me writing a complete standard library?
> You want me to embark on a multi-year project, just to provide an
> example for a paper?
Kind of, yes.
You're making an extraordinary claim in your proposal and making an
extraordinary requirement of standard library developers. You need to provide
extraordinary proof.
Right now, any Standard Library implementor who is reading this argument is
probably going to agree with me and not you, and therefore their votes in the
Standard process would be to reject your proposal. I want to help you come up
with a good proposal that has a chance of being accepted. I don't think it
will happen, but just in case I am wrong, I want you to have the best proposal
possible to support your claim.
> > I am looking at that and I addressed in my paragraph: the design was that
> > libstdc++ would keep ABI and strictly speaking, it did. The issue was
>
> I disagree with that. No 'design' was involved in the stability of
> libstdc++. Instead its developers realised, at some point, that they
> were no longer able to change anything because too many people relied on
> their existing ABI. Calling that 'design' is like falling of a ladder
> and then shouting "I meant to do that!"
You're disagreeing with facts.
The developers of libstdc++-v3, which produces libstdc++.so.6, clearly knew
back in the early 2000s the need about ABI stability. It's the third
implementation of libstdc++ and it's the sixth binary-incompatible release of
those libraries. They had the means to rev up when they broke ABI and they had
already used it before.
The most recent change was libstdc++.so.5 to 6, which happened in GCC 3.4. I
don't remember for sure that there were no changes to the ABI implementation
in the compiler from 3.3 to 3.4, but from what vague memory I have of the
event, the actual compiler-generated ABI (mangling scheme, etc.) was stable in
that release and backwards compatible with 3.3.
So, no, the need for ABI stability was well understood back then and was part
of the design of current libstdc++ today. And even if it wasn't, libc++ would
have no such excuse, because it's much newer and had the benefit of experience.
> My design removes the issue of ABI stability being poorly explained to
> library developers. It formalizes what is, and what isn't stable. It is
> precisely the answer to the problem you formulated here.
This is completely irrelevant.
First, you don't need to explain ABI or not to Standard Library developers.
They already know it. The only thing you're changing is that some API dictated
by the standard would be marked "subject to change" but as I argued in my
other email, we already have such a mechanism in the form of TRs and TSes.
Second, you're not explaining how doing anything helps the implementors write
more stable ABI. Saying "std::stable::string is stable" does not make it
stable. I'll repeat my question: given the implementors of the original
std::string thought it was stable, how does your proposal guide them to not
making the same mistake in std::stable::string?
> Sure, why not. FOR THE PURPOSE OF EXPOSITION, instead of implementing a
> stable class myself and defining its ABI, I'll borrow the existing class
> from the standard library. THIS IS NOT HOW IT WOULD WORK IN THE REAL
> WORLD, but it is close enough that it will suffice FOR AN EXAMPLE.
You misunderstood my question.
I don't want to see how it would be used by user code. I want to see how it
would be implemented, so we can judge performance limitations and how the new
design is (or fails to be) more conducive to keeping a long-term ABI.
> Are you actually serious about me writing a complete standard library?
> You want me to embark on a multi-year project, just to provide an
> example for a paper?
Kind of, yes.
You're making an extraordinary claim in your proposal and making an
extraordinary requirement of standard library developers. You need to provide
extraordinary proof.
Right now, any Standard Library implementor who is reading this argument is
probably going to agree with me and not you, and therefore their votes in the
Standard process would be to reject your proposal. I want to help you come up
with a good proposal that has a chance of being accepted. I don't think it
will happen, but just in case I am wrong, I want you to have the best proposal
possible to support your claim.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2024-07-13 13:51:50