>> If you have the code to build libraries from, then standard library
>> versioning is a solvable problem with existing tools.
>
> Then why did you give an example of a library (libstdc++'s std::string
> problem) for which the source is available?

Because building, say, clang and all of your code along with it, all with the same standard, would not produce an ABI issue.

In the case of std::string, the source was “available” in that it was open source, yes, but it was opaque. Many-a-library depend on the system-provided libc++.*

> There's nothing that can fix developer laziness. Any proposal you make requires
> developers to take action. If they don't, then it doesn't solve the problem.
>
> If the source for a given library is not available to me, then it means I'm
> paying for it. That means the developers can simply take my money and make the
> version that I need for my environment, or I'll stop using their product.
>
> And besides, the source may not be available to me, but it is available to
> someone. Therefore, the solution must contemplate source availability anyway.

I will think on this.

>> Cross-version compatibility is not an issue I anticipate. The opposite, in
>> fact, it is meant to make explicit that, say, the `std::string` which my
>> library is targeting is associated with C++98 to C++11; explicitly nothing
>> afterwards.
>
> How is that different from what we have today?

In some cases, a standard’s symbols might not change, but the binary layout will in consequential ways.

For example, if I hash a value from library A, send it to a map in library B, and try to look it up in library B (by its hash) from a value in library A, I’m assuming that:
1. Symbols exist for the hashing function and the map object
2. The hashing algorithm produces the same output when the symbol exists

1 and 2 might not always be true.

WL

> On Sep 19, 2022, at 10:53 PM, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Monday, 19 September 2022 19:46:53 PDT William Linkmeyer via Std-Proposals
> wrote:
>> I’m not sure I follow.
>>
>> If you have the code to build libraries from, then standard library
>> versioning is a solvable problem with existing tools.
>
> Then why did you give an example of a library (libstdc++'s std::string
> problem) for which the source is available?
>
>> This proposal is meant to address libraries for which the source code does
>> not exist or is not inspectable by making available a standard tool to
>> express standard compatibility.
>
> There's nothing that can fix developer laziness. Any proposal you make requires
> developers to take action. If they don't, then it doesn't solve the problem.
>
> If the source for a given library is not available to me, then it means I'm
> paying for it. That means the developers can simply take my money and make the
> version that I need for my environment, or I'll stop using their product.
>
> And besides, the source may not be available to me, but it is available to
> someone. Therefore, the solution must contemplate source availability anyway.
>
>> Cross-version compatibility is not an issue I anticipate. The opposite, in
>> fact, it is meant to make explicit that, say, the `std::string` which my
>> library is targeting is associated with C++98 to C++11; explicitly nothing
>> afterwards.
>
> How is that different from what we have today?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DCAI Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals