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.

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.

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.

Do I understand your points correctly?

WL

> On Sep 19, 2022, at 10:23 PM, Henry Miller via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Communication of version isn't even worth thinking about until you solve the interoperability problem. That is I have two unrelated libraries, one using std::foov1 and one std::foov2. How do i, in a performant and not too ugly way move data between these two libraries.
>
> So long as the above problem isn't solved I need to build everything against the same standard library and so a simple system wide flag is all we need. Or maybe some for of package config (currently there is no C++ package manager but many implementations have something. Cmake for example) my build system can throw an error if i'm mixing versiones.
>
> I have some ideas for how to solve the problem, but they only work in specific circumstances and not general. Where they work I don't need any marker like you propose. Though i'm open to other solutions that do. However either way, start by. Proposing something that breaks ABI, then propose a work around to allow mixing old and new (where new is aware of old), and then only if a marker is needed do we add it.
>
> --
> Henry Miller
> hank_at_[hidden]
>
>> On Mon, Sep 19, 2022, at 20:21, William Linkmeyer via Std-Proposals wrote:
>> # Versioned Standard
>>
>> ### Document: <awaiting>
>>
>> ### Date: September 19, 2022
>>
>> ### Audience: LEWG
>>
>> ### Reply To: willhl_at_[hidden]
>>
>> ## Introduction
>>
>> ABI stability is a communication problem. Libraries, meant to be
>> shared, often version themselves. The obvious purpose is to communicate
>> change over time.
>>
>> The standard library itself is often versioned. Some shared standard
>> library, `libc++.so.0`, may differ from some other shared standard
>> library, `libc++.so.9`.
>>
>> There is no reliable channel of communication between between libraries
>> and their associated standards.
>>
>> ## Motivation
>>
>> ABI is a perennial issue. Tools must be provided to users who wish to
>> specify their intended standard library version.
>>
>> ## Implementation
>>
>> Introduce the *language* template to specify the intended standard
>> version range to be used:
>>
>> ```c++
>> using std = std::v<2017, 2023>;
>> ```
>>
>> Which will embed an implementation-defined hint within the resulting binary.
>>
>> WL
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals