Date: Mon, 19 Sep 2022 21:55:23 -0400
On Mon, Sep 19, 2022 at 9:22 PM William Linkmeyer via Std-Proposals
<std-proposals_at_[hidden]> 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.
Libraries may version themselves, but version numbers are used for
more than just ABI instability. The ABI can be stable even if the
internal behavior has changed in some way that breaks your program.
> 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.
There is no reliable channel of communication between libraries at
all, even ignoring whether the standard library is involved. So even
if you could solve the issue regarding the standard library, the issue
remains for all other libraries.
> ## Motivation
>
> ABI is a perennial issue. Tools must be provided to users who wish to specify their intended standard library version.
"Must" is a strong word to be throwing around when your motivation
section is only two sentences long. Can you not provide any more
motivation than this? Like, maybe some code examples of problems that
can occur and how your suggestion would fix them?
> ## 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.
What does this actually do? It doesn't seem to do anything to the
language, and your chosen syntax reuses a keyword that already has
*three* almost entirely unrelated meanings.
<std-proposals_at_[hidden]> 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.
Libraries may version themselves, but version numbers are used for
more than just ABI instability. The ABI can be stable even if the
internal behavior has changed in some way that breaks your program.
> 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.
There is no reliable channel of communication between libraries at
all, even ignoring whether the standard library is involved. So even
if you could solve the issue regarding the standard library, the issue
remains for all other libraries.
> ## Motivation
>
> ABI is a perennial issue. Tools must be provided to users who wish to specify their intended standard library version.
"Must" is a strong word to be throwing around when your motivation
section is only two sentences long. Can you not provide any more
motivation than this? Like, maybe some code examples of problems that
can occur and how your suggestion would fix them?
> ## 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.
What does this actually do? It doesn't seem to do anything to the
language, and your chosen syntax reuses a keyword that already has
*three* almost entirely unrelated meanings.
Received on 2022-09-20 01:56:14