On Mon, Jul 22, 2024, at 16:22, Hans via Std-Proposals wrote:
> On 21/07/2024 19:02, Bjorn Reese via Std-Proposals wrote:
>> On 7/21/24 17:51, Hans via Std-Proposals wrote:
>>
>>> I want to be able to mark some datastructures as guaranteed-stable,
>>> and for the rest of the datastructures to have no stability guarantee.
> >
>> Have you considered a more radical approach, where these ABI classes
>> only holds data? They may have constructors, destructors, and simple
>> accessors, but nothing else. These ABI classes are wrapped by API
>> classes that holds the functionality. The ABI classes must be easy
>> to move to API classes. Alternatively, or complementarily, the
>> functionality may reside in standalone functions.
>
> I'm not sure how that changes anything?
>
> Of course, if this becomes a reality, other languages would need
> accessor functions they can call, and for a language like C that would
> involve this type of approach. But for C++ it isn't necessarily an
> improvement.

That is exactly what it changes. If you have a standard layout data structure I can use it in not just C++, but also C, rust, ada, or whatever the language of interest is. I can design a FPGA to do special processing of this data. I can pass it off to a GPU. I can mix CPUs on the same board and pass data between them.

In theory I could look up how my C++ library lays out the data and do all of the above. However I'm then locked into one std library. Building for both windows (msvc) and linux (libstdcxx) is common and that makes the above impossible.

Without this your proposal is a non-starter. The standard defines the library in terms of algorithms which have been researched for decades, and so all the data your class needs is obvious despite not being specified. You can change the order, but that will never matter much (microbenchmarks may find an optimal order, but even the least optimal order will still be close in performance), and so there is little call to change the ABI of classes in the standard library in the first place (not zero, but not a lot).

>> This allows the addition and removal of functionality without affecting
>> the ABI.
>
> You can do that anyway. Adding or removing non-virtual member functions
> doesn't change the ABI.

What functionality do you want to add the standard library that breaks ABI? I can think of a few, but all end up being things that show up in microbenchmarks but won't have a large real world effect. As such the argument for changing ABI isn't very strong.