>
> 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


 Very simple solution that doesn't require a lot of umming and uhhing from
that commitee, or even their involvment at all. Just get compilers to
implement an extension like "__attribute__((abi(msc))". Where ever there's
a difference in ABI implementation the attribute would tell the compiler to
forgo it's usual implementation and use the specified compiler's
implementation. This would resolve that __thiscall thing mentioned earlier
in classes as a simple "__attribute__((abi(msc)) class stdabi::ns::ver {
... }"

On Tue, 23 Jul 2024 at 16:11, Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>