On 23/07/2024 02:34, Thiago Macieira via Std-Proposals wrote:
> 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.

It does, in the section 'non-viable solutions'.

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

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.

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.

So why should that same principle not apply to the standard library?

Habit?

Historical reasons?

Why not add a mechanism to ALLOW that kind of iteration to the standard
library?

"Because the vendors don't like it?" I imagine the vendors would be
positively delighted by not having to get every class exactly right on
the first release. They would be a huge beneficiary of this plan.

And you get interoperability as well! Between standard libraries, and
even with other languages.

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

If that is the proper path, someone should update that website. And
provide contact details for the vendors, in particular Microsoft, which
I'm positive is not going to respond to anything I have to say.

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

I said they _can_, not that they _will_.

They have done it in the past.

There is no guarantee they won't do it again in the future.

You can even do it yourself, by virtue of switching from release to
debug, or vice versa.

If it's guaranteed to be stable, add a line to the Standard to give
people that guarantee. But I prefer my solution.

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

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.

Perhaps we need a third state for classes?

1. 'stable' = formally stable. The ABI is pre-specified and known,
allowing interoperability.

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.

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.

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

As I said, I would prefer to take this opportunity to also address
interoperability concerns.


Hans Guijt