Date: Sat, 13 Jul 2024 16:10:43 -0700
On Saturday 13 July 2024 08:33:57 GMT-7 Hans via Std-Proposals wrote:
> > You're making an extraordinary claim in your proposal and making an
> > extraordinary requirement of standard library developers. You need to
> > provide extraordinary proof.
>
> What? What is extraordinary about my claim? No, scratch that, what do
> you even think I'm claiming? How is adding FOUR SIMPLE CLASSES an
> extraordinary requirement?
If they are simple, please provide the implementation.
You're asking that the Standard Library add a new set of classes that promises
stability. But you have not provided any evidence or method by which such new
classes would be more stable than the current classes are right now and have
been for two decades.
> I want the default for classes to be unstable. Nobody has to do
> anything, anything at all, to make that happen, it's just a default.
Ok, now this is a new argument.
First, are you referring to *new* classes to be added to the standard? If so,
we already have mechanisms to do what you're saying. There's no need to have a
new paper. Of course, classes are added to the experimental set with eye
towards becoming stable, eventually.
Or are you proposing that the current classes become unstable? Why would we
want that? What's the transition mechanism for people who currently rely on
the fact that they are stable?
> The
> entire standard library stays as it is, unchanged, identical, the same,
> no changes. Then we go and add... FOUR CLASSES. Why do you want me to
> write a bloody standard library just to demonstrate that you can add
> FOUR CLASSES to it? Did you make that same COMPLETELY UNHINGED demand of
> the people that wanted to add std::flatmap? Because that got added, and
> I assure you it is way more code than what I'm proposing.
No, I didn't because their fundamental development of the class wasn't
different. See above for why.
If you think my request is unhinged, then it's a good chance that we're
misunderstanding each other. Quite frankly, I still don't know what you want.
Maybe you do need to write a paper in detail, because just the email
discussion isn't getting to the point.
> If you really want to help, you can start by READING THE PROPOSAL, and
> suggesting improvements to the text. That would be a far greater help
> than just endlessly repeating demands for information that is already in
> the proposal anyway.
>
> You can find the proposal here:
> https://docs.google.com/document/d/1P1mL1J0rXJlRnLYrcquzLVqE3jPd_IC6uQYnMIE6
> 8vA/edit
Fair.
In "What are the issues with ABI?", you say that there is no guarantee of
interoperability between different versions of a single implementation of the
standard library. That's false. All three major implementations do promise it.
Next, you claim that implementors have reluctance in optimising. That's false
too: there is a lot of optimisation work that goes in all three in every
release. Yes, their hands are tied by the ABI, but that does not preclude all
optimisation. You are correct that some forms would be disallowed, but your
statement does not say that. It's overly broad. Plus, you have to show
evidence that such disallowed optimisation would be wanted: please provide a
few examples of where that could have happened but for the need to keep ABI.
std::regex is not such an example. The reason it isn't being changed is not
ABI, but behaviour, in particular of the flavour of regular expression that
class supports. Applications are written with an expectation in mind and that
is what the Standard is for. Changing std::regex would break the Standard's
promise, so it would be far easier to add a new class and deprecate the old
one until it can be safely removed (q.v. Qt5 adding QRegularExpression that
replaced the old QRegExp, and Qt6 removed the latter).
The next bullet point says there's a reluctance in the committee members in
evolving classes for fear of breaking the ABI. While that is true to some
extent, your paper would benefit from more examples. You cannot generalise on
one example alone.
You refer to two strategies to keeping ABI from C, but you failed to note that
as a derivative from C, C++ already has the two available. More importantly,
C++ has been using those two strategies for 30 years. The majority of the
Standard Library class implementations are actually of the "set in stone" type
of structure, while the opaque handle type is what Qt has very successfully
used for 30 years too. So saying "good candidate for adoption into C++" is
unnecessary, since C++ already adopted the two 30 years ago.
And given that C++ *has* adopted them and you claim that there are ABI
problems, you need to discuss why.
Your solution is proposed to declare which classes are stable and which may
not. I'm claiming we already have that, it just happens that the entirety of
the Standard Library is in the former category, while the experimental stuff is
found in Technical Reports. Moreover, library implementors have availed
themselves of techniques to mark their implementations of the future-stable
Standard Library as "in development". Therefore, I am claiming that your
proposal was adopted with great success, 30 years ago.
Providing tools to enforce by the compiler so one knows whether they are using
unstable ABI in their content that itself marked for stability would be nice.
Can you expand your paper with the actual mechanisms by which the compiler
should do that? Not a placeholder.
You're saying that a stable class must be standard layout. Why? That seems
unnecessary.
You should answer your question on pointers too; don't leave the question
open. In doing so, you should also ponder what happens to a class like
std::unique_ptr<T> where T is not explicitly marked stable.
In discussing the stability of the standard library, you say that it does not
help with interfacing with other standard libraries. That's true. It's not
desired, so it's also not a problem.
You then propose that the current classes in the Standard Library not be
marked as stable. That has a huge effect that you're not addressing at all in
your paper. Developers *expect* stability and have come to rely on it for the
Standard Library as it is today. Voiding that contract is either going to be
shot down very quickly, or you need to provide a path to mitigating the
effects.
Or, alternatively, that's a distinction without a difference, in that the
implementations will keep the stability whether the Standard mandates it or
not, and will still require the Standard not to change in a way that breaks
that promised stability. In that case, we'd have to wonder why we need a
special group of classes that promise no more stability than the existing
grouping does.
In the std::stable namespace section, you say "committee-supplied ABI" but
that's woefully short of details. Is it just a description of the class layout
in the form of a C structure (and hence the "standard layout" requirement from
above")? If so, say so. For me, ABI implies much more, including the size and
alignment of types, which the committee could never provide for all possible
target architectures.
There are other ABI problems that would need addressing. For example, whether
a parameter passed by value is destroyed by the caller or by the callee. This
differs between the MinGW ABI used by Clang and GCC on Windows and the MSVC
ABI. If your intent was to allow passing of non-trivially-destructible types
as parameters across Standard Libraries (assuming the name mangling is not an
impediment), you'd need to somehow fix this problem. Another one is for the two
classes that allocate memory in your proposal: std::string and std::vector.
Without solving the problem of name mangling, the there may be two ::operator
new / ::operator delete pairs, and therefore deleting memory allocated by the
other cannot be guaranteed to work.
There will probably be more problems. Therefore, this paper is not going to
advance until there is concrete proof of it working and the problems having
been solved. It needs an implementation provided by its supporters to show
that it can work and that the problems have solutions.
Because if it can't show that, then communication across implementations using
C++ types is still impossible, and thus the stability is confined to inside of
a single Standard Library implementation. And that brings us back to where we
are today: those libraries pretty stable.
> If you believe that there is no ABI issue, there is no point in
> discussing: you don't believe there is an issue, and from your
> perspective EVERYTHING I say is wasted effort. There is no need for you
> to engage in that case.
I did not say it's a wasted effort. I am merely skeptical that this is a
workable solution. But improving your proposal may reveal that I am wrong.
I am also very skeptical that there is a problem to be solved in the first
place. The implementations are stable, the cases where a change was desired
but not permitted due to stability are few and far between, usually minor, and
communication between Standard Libraries may be desired by users, but not by
the implementors themselves so attempt to move in that direction is unlikely
to gain traction.
Finally, your working on the proposal may spur other ideas in parallel tracks
that are workable. In particular, I am very interested in a way to mark
functions and classes exported from libraries and, by consequence, marking
what is internal and thus subject to change.
> If you DO believe there is an issue (and you've held both positions in
> your various emails so I don't know which it is), we can discuss my
> proposed solution. Or, if you think you have a better idea, tell us
> about it.
I don't have a better idea.
But here's a suggestion: your paper seems to be addressing three things in
one. It might be adviseable to split and address each in sequence:
a) a core language change to the syntax that would allow marking of classes
and functions as stable
(I'm not particularly interested in the stability argument, but as I said
above, a syntax for exporting and importing across dynamic library boundaries
is very much needed)
b) an addition to the Standard Library of some classes whose memory layout is
more tightly defined by the Standard, with an eye towards communication between
Standard Library implementations and possibly with other languages. You can
rely on all the C ABI, but you'll need to define every single behaviour above
that of C, like when destructors get run.
(Personally, I think this is the most interesting portion)
c) a discussion of relaxing the current stability requirements in the regular
classes in the Standard Library, with the possible fall-outs and transition
mechanisms.
(this one I would vehemently oppose)
> > You're making an extraordinary claim in your proposal and making an
> > extraordinary requirement of standard library developers. You need to
> > provide extraordinary proof.
>
> What? What is extraordinary about my claim? No, scratch that, what do
> you even think I'm claiming? How is adding FOUR SIMPLE CLASSES an
> extraordinary requirement?
If they are simple, please provide the implementation.
You're asking that the Standard Library add a new set of classes that promises
stability. But you have not provided any evidence or method by which such new
classes would be more stable than the current classes are right now and have
been for two decades.
> I want the default for classes to be unstable. Nobody has to do
> anything, anything at all, to make that happen, it's just a default.
Ok, now this is a new argument.
First, are you referring to *new* classes to be added to the standard? If so,
we already have mechanisms to do what you're saying. There's no need to have a
new paper. Of course, classes are added to the experimental set with eye
towards becoming stable, eventually.
Or are you proposing that the current classes become unstable? Why would we
want that? What's the transition mechanism for people who currently rely on
the fact that they are stable?
> The
> entire standard library stays as it is, unchanged, identical, the same,
> no changes. Then we go and add... FOUR CLASSES. Why do you want me to
> write a bloody standard library just to demonstrate that you can add
> FOUR CLASSES to it? Did you make that same COMPLETELY UNHINGED demand of
> the people that wanted to add std::flatmap? Because that got added, and
> I assure you it is way more code than what I'm proposing.
No, I didn't because their fundamental development of the class wasn't
different. See above for why.
If you think my request is unhinged, then it's a good chance that we're
misunderstanding each other. Quite frankly, I still don't know what you want.
Maybe you do need to write a paper in detail, because just the email
discussion isn't getting to the point.
> If you really want to help, you can start by READING THE PROPOSAL, and
> suggesting improvements to the text. That would be a far greater help
> than just endlessly repeating demands for information that is already in
> the proposal anyway.
>
> You can find the proposal here:
> https://docs.google.com/document/d/1P1mL1J0rXJlRnLYrcquzLVqE3jPd_IC6uQYnMIE6
> 8vA/edit
Fair.
In "What are the issues with ABI?", you say that there is no guarantee of
interoperability between different versions of a single implementation of the
standard library. That's false. All three major implementations do promise it.
Next, you claim that implementors have reluctance in optimising. That's false
too: there is a lot of optimisation work that goes in all three in every
release. Yes, their hands are tied by the ABI, but that does not preclude all
optimisation. You are correct that some forms would be disallowed, but your
statement does not say that. It's overly broad. Plus, you have to show
evidence that such disallowed optimisation would be wanted: please provide a
few examples of where that could have happened but for the need to keep ABI.
std::regex is not such an example. The reason it isn't being changed is not
ABI, but behaviour, in particular of the flavour of regular expression that
class supports. Applications are written with an expectation in mind and that
is what the Standard is for. Changing std::regex would break the Standard's
promise, so it would be far easier to add a new class and deprecate the old
one until it can be safely removed (q.v. Qt5 adding QRegularExpression that
replaced the old QRegExp, and Qt6 removed the latter).
The next bullet point says there's a reluctance in the committee members in
evolving classes for fear of breaking the ABI. While that is true to some
extent, your paper would benefit from more examples. You cannot generalise on
one example alone.
You refer to two strategies to keeping ABI from C, but you failed to note that
as a derivative from C, C++ already has the two available. More importantly,
C++ has been using those two strategies for 30 years. The majority of the
Standard Library class implementations are actually of the "set in stone" type
of structure, while the opaque handle type is what Qt has very successfully
used for 30 years too. So saying "good candidate for adoption into C++" is
unnecessary, since C++ already adopted the two 30 years ago.
And given that C++ *has* adopted them and you claim that there are ABI
problems, you need to discuss why.
Your solution is proposed to declare which classes are stable and which may
not. I'm claiming we already have that, it just happens that the entirety of
the Standard Library is in the former category, while the experimental stuff is
found in Technical Reports. Moreover, library implementors have availed
themselves of techniques to mark their implementations of the future-stable
Standard Library as "in development". Therefore, I am claiming that your
proposal was adopted with great success, 30 years ago.
Providing tools to enforce by the compiler so one knows whether they are using
unstable ABI in their content that itself marked for stability would be nice.
Can you expand your paper with the actual mechanisms by which the compiler
should do that? Not a placeholder.
You're saying that a stable class must be standard layout. Why? That seems
unnecessary.
You should answer your question on pointers too; don't leave the question
open. In doing so, you should also ponder what happens to a class like
std::unique_ptr<T> where T is not explicitly marked stable.
In discussing the stability of the standard library, you say that it does not
help with interfacing with other standard libraries. That's true. It's not
desired, so it's also not a problem.
You then propose that the current classes in the Standard Library not be
marked as stable. That has a huge effect that you're not addressing at all in
your paper. Developers *expect* stability and have come to rely on it for the
Standard Library as it is today. Voiding that contract is either going to be
shot down very quickly, or you need to provide a path to mitigating the
effects.
Or, alternatively, that's a distinction without a difference, in that the
implementations will keep the stability whether the Standard mandates it or
not, and will still require the Standard not to change in a way that breaks
that promised stability. In that case, we'd have to wonder why we need a
special group of classes that promise no more stability than the existing
grouping does.
In the std::stable namespace section, you say "committee-supplied ABI" but
that's woefully short of details. Is it just a description of the class layout
in the form of a C structure (and hence the "standard layout" requirement from
above")? If so, say so. For me, ABI implies much more, including the size and
alignment of types, which the committee could never provide for all possible
target architectures.
There are other ABI problems that would need addressing. For example, whether
a parameter passed by value is destroyed by the caller or by the callee. This
differs between the MinGW ABI used by Clang and GCC on Windows and the MSVC
ABI. If your intent was to allow passing of non-trivially-destructible types
as parameters across Standard Libraries (assuming the name mangling is not an
impediment), you'd need to somehow fix this problem. Another one is for the two
classes that allocate memory in your proposal: std::string and std::vector.
Without solving the problem of name mangling, the there may be two ::operator
new / ::operator delete pairs, and therefore deleting memory allocated by the
other cannot be guaranteed to work.
There will probably be more problems. Therefore, this paper is not going to
advance until there is concrete proof of it working and the problems having
been solved. It needs an implementation provided by its supporters to show
that it can work and that the problems have solutions.
Because if it can't show that, then communication across implementations using
C++ types is still impossible, and thus the stability is confined to inside of
a single Standard Library implementation. And that brings us back to where we
are today: those libraries pretty stable.
> If you believe that there is no ABI issue, there is no point in
> discussing: you don't believe there is an issue, and from your
> perspective EVERYTHING I say is wasted effort. There is no need for you
> to engage in that case.
I did not say it's a wasted effort. I am merely skeptical that this is a
workable solution. But improving your proposal may reveal that I am wrong.
I am also very skeptical that there is a problem to be solved in the first
place. The implementations are stable, the cases where a change was desired
but not permitted due to stability are few and far between, usually minor, and
communication between Standard Libraries may be desired by users, but not by
the implementors themselves so attempt to move in that direction is unlikely
to gain traction.
Finally, your working on the proposal may spur other ideas in parallel tracks
that are workable. In particular, I am very interested in a way to mark
functions and classes exported from libraries and, by consequence, marking
what is internal and thus subject to change.
> If you DO believe there is an issue (and you've held both positions in
> your various emails so I don't know which it is), we can discuss my
> proposed solution. Or, if you think you have a better idea, tell us
> about it.
I don't have a better idea.
But here's a suggestion: your paper seems to be addressing three things in
one. It might be adviseable to split and address each in sequence:
a) a core language change to the syntax that would allow marking of classes
and functions as stable
(I'm not particularly interested in the stability argument, but as I said
above, a syntax for exporting and importing across dynamic library boundaries
is very much needed)
b) an addition to the Standard Library of some classes whose memory layout is
more tightly defined by the Standard, with an eye towards communication between
Standard Library implementations and possibly with other languages. You can
rely on all the C ABI, but you'll need to define every single behaviour above
that of C, like when destructors get run.
(Personally, I think this is the most interesting portion)
c) a discussion of relaxing the current stability requirements in the regular
classes in the Standard Library, with the possible fall-outs and transition
mechanisms.
(this one I would vehemently oppose)
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2024-07-13 23:10:50