Date: Mon, 22 Jul 2024 17:34:02 -0700
On Monday 22 July 2024 14:22:24 GMT-7 Hans via Std-Proposals wrote:
> > Good. Please explain why this needs to be anything beyond documentation in
> > your library.
>
> That's in the paper. The paper presents the problem with the reasons for
> solving it this way.
It should discuss alternatives that were rejected and why they were rejected.
> > Please explain how that will improve the interface design in C++ in
> > general
> > above and beyond what we already have. There must be a problem that
> > prevents its current design that makes interfaces currently designed
> > sub-optimal and your proposal thus makes easier to achieve and/or
> > maintain.
>
> It will stop people from using unstable classes in their public
> interfaces. It will allow you to safely transport strings and vectors
> through public interfaces without dealing with manual memory management,
> or zero-terminated strings, or _hopefully_ long enough buffers. It will
> improve safety, and it will avoid locking every single C++ class into
> de-facto stability the moment it is released.
Rephrasing my ask:
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.
> > As for freeing the Standard Library from its current ABI restrictions,
> > have
> > you asked the vendors if they want this? There are only three major
>
> No. The process for the ISO standard is laid out on
> https://isocpp.org/std/submit-a-proposal. It does not involve "ask
> vendors if they want this".
While that's true, it's pretty self-defeating to propose something that you
know the implementations will vote down. It will most likely never leave the
LEWG.
> >> And for good measure: I do not want to break the ABI of existing
> >> standard library classes either.
> >
> > Good.
> >
> > But why is then your goal to allow the implementations to do that?
>
> I have explained this. We currently have de-facto stability, but relying
> on that stability is UB because class ABI _can_ change at any moment.
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?
> Once stability marking becomes a reality, the standard will formally
> describe the consequences of relying on unstable classes in public
> interfaces. It will also specify which classes are ABI stable.
Sure. But see above: we already have a mechanism for this. It just happens
that the set contains all classes.
> That means that classes that are added AFTER stability marking becomes a
> reality, CAN and SHOULD BE EXPECTED TO be changed over time. That is,
> FUTURE ADDITIONS to the standard library can be expected to be unstable,
> and any use of such classes in a public interface is EXPLICITLY UB.
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.
> However, since this is a new rule, and since EXISTING standard library
> classes are ALREADY used in public interfaces, EXISTING classes,
> although FORMALLY unstable, retain their current status as de-facto
> stable, in order not to break compatibility of existing software.
Why not make them de jure stable if they are de facto stable?
> If existing classes are in need of optimisation, vendors are free to
> propose adding an unstable class2 version to the standard library. Since
> that would count as a new addition, it will default to being unstable,
> and therefore open to evolution. This allows targeted improvement of the
> worst problems in the standard library.
I still don't see any innovation here.
We already have everything that you're proposing and more.
> > Good. Please explain why this needs to be anything beyond documentation in
> > your library.
>
> That's in the paper. The paper presents the problem with the reasons for
> solving it this way.
It should discuss alternatives that were rejected and why they were rejected.
> > Please explain how that will improve the interface design in C++ in
> > general
> > above and beyond what we already have. There must be a problem that
> > prevents its current design that makes interfaces currently designed
> > sub-optimal and your proposal thus makes easier to achieve and/or
> > maintain.
>
> It will stop people from using unstable classes in their public
> interfaces. It will allow you to safely transport strings and vectors
> through public interfaces without dealing with manual memory management,
> or zero-terminated strings, or _hopefully_ long enough buffers. It will
> improve safety, and it will avoid locking every single C++ class into
> de-facto stability the moment it is released.
Rephrasing my ask:
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.
> > As for freeing the Standard Library from its current ABI restrictions,
> > have
> > you asked the vendors if they want this? There are only three major
>
> No. The process for the ISO standard is laid out on
> https://isocpp.org/std/submit-a-proposal. It does not involve "ask
> vendors if they want this".
While that's true, it's pretty self-defeating to propose something that you
know the implementations will vote down. It will most likely never leave the
LEWG.
> >> And for good measure: I do not want to break the ABI of existing
> >> standard library classes either.
> >
> > Good.
> >
> > But why is then your goal to allow the implementations to do that?
>
> I have explained this. We currently have de-facto stability, but relying
> on that stability is UB because class ABI _can_ change at any moment.
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?
> Once stability marking becomes a reality, the standard will formally
> describe the consequences of relying on unstable classes in public
> interfaces. It will also specify which classes are ABI stable.
Sure. But see above: we already have a mechanism for this. It just happens
that the set contains all classes.
> That means that classes that are added AFTER stability marking becomes a
> reality, CAN and SHOULD BE EXPECTED TO be changed over time. That is,
> FUTURE ADDITIONS to the standard library can be expected to be unstable,
> and any use of such classes in a public interface is EXPLICITLY UB.
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.
> However, since this is a new rule, and since EXISTING standard library
> classes are ALREADY used in public interfaces, EXISTING classes,
> although FORMALLY unstable, retain their current status as de-facto
> stable, in order not to break compatibility of existing software.
Why not make them de jure stable if they are de facto stable?
> If existing classes are in need of optimisation, vendors are free to
> propose adding an unstable class2 version to the standard library. Since
> that would count as a new addition, it will default to being unstable,
> and therefore open to evolution. This allows targeted improvement of the
> worst problems in the standard library.
I still don't see any innovation here.
We already have everything that you're proposing and more.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2024-07-23 00:34:06