Date: Tue, 23 Jul 2024 08:11:28 -0700
On Tuesday 23 July 2024 00:31:37 GMT-7 Hans via Std-Proposals wrote:
> On 23/07/2024 02:34, Thiago Macieira via Std-Proposals wrote:
> > It should discuss alternatives that were rejected and why they were
> > rejected.
> It does, in the section 'non-viable solutions'.
Please add a few more entries to that list:
* marking simply in documentation
* marking by having experimental content in other namespaces
* marking by making experimental content fail to compile or link without
express (implementation-defined) opt-in
> > We already have a mechanism for library implementors to implement content
> > that is still subject to change and we have a mechanism for the Standard
> > to provide content that is subject to change. So please explain why these
> > mechanisms aren't enough and we need something different. Please explain
> > why your proposed interfaces will not have the same problem that a change
> > is required in the future.
>
> That mechanism assumes a one-off implementation that leads to perfection
> on short notice. This is simply not how software is developed out in the
> real world.
I agree with the statement in general. But the history of the Standard Library
is the exception to the rule. See Henry's reply, that what we add to the
Standard Library is (usually) well-researched and known for decades.
But you didn't answer my point that the Standard can declare content
experimental and the implementations have means to publishing content that
they aren't sure of either.
> You said you maintain Qt. Qt has had HUNDREDS of versions, each changing
> stuff. Surely you appreciate that complex software takes multiple
> iterations to get right.
Indeed, we've made more than a hundred releases in the past 20 years. Do you
know how many of them intentionally broke ABI? Three:
Qt 4.0
Qt 5.0
Qt 6.0
In the case of 6.0, we didn't *need* to. There were things we didn't like and
had scheduled for fixing (like we have for 7.0 today), but there wasn't
anything egregiously broken that required a fix. We just felt it was time to
apply the clean-up that had accumulated.
> So why should that same principle not apply to the standard library?
>
> Habit?
>
> Historical reasons?
No.
First, it's size: the Standard Library is a comparatively small set of classes
and functionality compared to Qt or Boost or Folly or other such big
libraries. That reduces the need for breaking because there is less that might
need it.
Second, it's past knowledge. As Henry said, the algorithms are usually well-
known and have been known for decades. Then there's the fact that many of the
content getting standardised is coming from one of the other libraries as
prototyping phase, in particular Boost. So most of the breakage that you're
speaking of that happens when multiple iterations are required to get it right
have happened in those libraries.
> Why not add a mechanism to ALLOW that kind of iteration to the standard
> library?
We *have* that mechanism (TSs and such). You have not addressed this in your
proposal yet.
> And you get interoperability as well! Between standard libraries, and
> even with other languages.
That is a worthwhile goal but does not necessarily follow from your proposal.
This probably deserves its own, separate paper.
> > Except that it can't, because the *implementations* know what would break
> > ABI. We are beyond the Standard at that point. The implementations have
> > 20+ years of experience in not breaking ABI, so why do you say that they
> > will any moment?
>
> I said they _can_, not that they _will_.
>
> They have done it in the past.
Yes, they have. libstdc++ has done it once and it was mostly unintentional
(see my email on this). libc++ has not done it. MS STL has not done it since
they decided they weren't going to.
> There is no guarantee they won't do it again in the future.
Correct. But the Standard can't mandate that they won't, even with your
classes.
However, what makes them not break it is the need of their users. Since that
is there regardless of the Standard, they will keep compatibility even if the
Standard does not require of them.
> > Agreed. I want that. But put the entire current set of classes in the list
> > of those marked stable, because we are depending on them being stable and
> > they are kept stable.
>
> That is an option. However, I would prefer to keep those classes as
> de-facto stable instead of formally stable.
>
> Doing so has the significant advantage of ALSO granting us
> interoperability, between standard libraries and with other languages.
I personally don't care about compatibility with other languages. I can use C
interfaces for that and the problem of generating Qt bindings to Java and
Python is a solved one. I don't need the Standard to help me pass data in a
format that neither my C++ side nor my other-language side keep.
And I don't see how the conclusion follows. As I said above: adding classes
that are interoperable with other languages has a value of its own, but that's
orthogonal to having compatibility of the current content with itself in past
releases.
As for compatibility between standard libraries, again: who needs this? We've
been living with three of them in major, general-purpose OSes for 15 years and
that's a *reduction* from the 2000s. Do the standard libraries want to
interoperate?
*Can* they, given different name-mangling and argument passing? Because of
this, the interface between two different standard libraries would necessarily
need to be described in C, not in C++ format. There *cannot* be any out-of-
line member functions. So to achieve this, we'd need to force the standard
library implementors to start their own forum on how to describe the common
ABI that the C++ Standard would mandate. It's a lot of work that I am not sure
is called for and is very likely going to be voted down.
If you remove the compatibility with other languages and other standard
library implementations, all that remains is compatibility with past versions
of itself. Which we already have.
> Perhaps we need a third state for classes?
>
> 1. 'stable' = formally stable. The ABI is pre-specified and known,
> allowing interoperability.
Described in C, with non-member extern "C" functions, in the global namespace.
Why should this be in the C++ Standard?
And all my questions about who needs this.
> 2. 'closed' = informally stable. The ABI is whatever it happens to be.
> There is no interoperability guarantee, but if you are careful to not
> mix standard libraries, use the right compile mode, and don't upgrade
> your compiler too far, you can use them in public interfaces.
This is what we already have.
> 3. 'unstable' = formally unstable. The ABI is whatever it happens to be,
> and may change when new versions are released. There is no expectation
> of interoperability, and use in public interfaces is definitely advised
> against.
"Experimental". We already have this too.
> On 23/07/2024 02:34, Thiago Macieira via Std-Proposals wrote:
> > It should discuss alternatives that were rejected and why they were
> > rejected.
> It does, in the section 'non-viable solutions'.
Please add a few more entries to that list:
* marking simply in documentation
* marking by having experimental content in other namespaces
* marking by making experimental content fail to compile or link without
express (implementation-defined) opt-in
> > We already have a mechanism for library implementors to implement content
> > that is still subject to change and we have a mechanism for the Standard
> > to provide content that is subject to change. So please explain why these
> > mechanisms aren't enough and we need something different. Please explain
> > why your proposed interfaces will not have the same problem that a change
> > is required in the future.
>
> That mechanism assumes a one-off implementation that leads to perfection
> on short notice. This is simply not how software is developed out in the
> real world.
I agree with the statement in general. But the history of the Standard Library
is the exception to the rule. See Henry's reply, that what we add to the
Standard Library is (usually) well-researched and known for decades.
But you didn't answer my point that the Standard can declare content
experimental and the implementations have means to publishing content that
they aren't sure of either.
> You said you maintain Qt. Qt has had HUNDREDS of versions, each changing
> stuff. Surely you appreciate that complex software takes multiple
> iterations to get right.
Indeed, we've made more than a hundred releases in the past 20 years. Do you
know how many of them intentionally broke ABI? Three:
Qt 4.0
Qt 5.0
Qt 6.0
In the case of 6.0, we didn't *need* to. There were things we didn't like and
had scheduled for fixing (like we have for 7.0 today), but there wasn't
anything egregiously broken that required a fix. We just felt it was time to
apply the clean-up that had accumulated.
> So why should that same principle not apply to the standard library?
>
> Habit?
>
> Historical reasons?
No.
First, it's size: the Standard Library is a comparatively small set of classes
and functionality compared to Qt or Boost or Folly or other such big
libraries. That reduces the need for breaking because there is less that might
need it.
Second, it's past knowledge. As Henry said, the algorithms are usually well-
known and have been known for decades. Then there's the fact that many of the
content getting standardised is coming from one of the other libraries as
prototyping phase, in particular Boost. So most of the breakage that you're
speaking of that happens when multiple iterations are required to get it right
have happened in those libraries.
> Why not add a mechanism to ALLOW that kind of iteration to the standard
> library?
We *have* that mechanism (TSs and such). You have not addressed this in your
proposal yet.
> And you get interoperability as well! Between standard libraries, and
> even with other languages.
That is a worthwhile goal but does not necessarily follow from your proposal.
This probably deserves its own, separate paper.
> > Except that it can't, because the *implementations* know what would break
> > ABI. We are beyond the Standard at that point. The implementations have
> > 20+ years of experience in not breaking ABI, so why do you say that they
> > will any moment?
>
> I said they _can_, not that they _will_.
>
> They have done it in the past.
Yes, they have. libstdc++ has done it once and it was mostly unintentional
(see my email on this). libc++ has not done it. MS STL has not done it since
they decided they weren't going to.
> There is no guarantee they won't do it again in the future.
Correct. But the Standard can't mandate that they won't, even with your
classes.
However, what makes them not break it is the need of their users. Since that
is there regardless of the Standard, they will keep compatibility even if the
Standard does not require of them.
> > Agreed. I want that. But put the entire current set of classes in the list
> > of those marked stable, because we are depending on them being stable and
> > they are kept stable.
>
> That is an option. However, I would prefer to keep those classes as
> de-facto stable instead of formally stable.
>
> Doing so has the significant advantage of ALSO granting us
> interoperability, between standard libraries and with other languages.
I personally don't care about compatibility with other languages. I can use C
interfaces for that and the problem of generating Qt bindings to Java and
Python is a solved one. I don't need the Standard to help me pass data in a
format that neither my C++ side nor my other-language side keep.
And I don't see how the conclusion follows. As I said above: adding classes
that are interoperable with other languages has a value of its own, but that's
orthogonal to having compatibility of the current content with itself in past
releases.
As for compatibility between standard libraries, again: who needs this? We've
been living with three of them in major, general-purpose OSes for 15 years and
that's a *reduction* from the 2000s. Do the standard libraries want to
interoperate?
*Can* they, given different name-mangling and argument passing? Because of
this, the interface between two different standard libraries would necessarily
need to be described in C, not in C++ format. There *cannot* be any out-of-
line member functions. So to achieve this, we'd need to force the standard
library implementors to start their own forum on how to describe the common
ABI that the C++ Standard would mandate. It's a lot of work that I am not sure
is called for and is very likely going to be voted down.
If you remove the compatibility with other languages and other standard
library implementations, all that remains is compatibility with past versions
of itself. Which we already have.
> Perhaps we need a third state for classes?
>
> 1. 'stable' = formally stable. The ABI is pre-specified and known,
> allowing interoperability.
Described in C, with non-member extern "C" functions, in the global namespace.
Why should this be in the C++ Standard?
And all my questions about who needs this.
> 2. 'closed' = informally stable. The ABI is whatever it happens to be.
> There is no interoperability guarantee, but if you are careful to not
> mix standard libraries, use the right compile mode, and don't upgrade
> your compiler too far, you can use them in public interfaces.
This is what we already have.
> 3. 'unstable' = formally unstable. The ABI is whatever it happens to be,
> and may change when new versions are released. There is no expectation
> of interoperability, and use in public interfaces is definitely advised
> against.
"Experimental". We already have this too.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2024-07-23 15:11:30