Date: Thu, 11 Jul 2024 13:57:47 +0200
On 10/07/2024 14:57, Thiago Macieira via Std-Proposals wrote:
> On Wednesday 10 July 2024 03:01:39 GMT-7 Hans via Std-Proposals wrote:
>> The focus of the paper is not on how to implement such interfaces,
>> however, it is on communicating (and enforcing) that library classes are
>> subject to change in future library revisions, and therefore not safe to
>> use in public interfaces.
>
> Can you give examples of Standard Library classes that would be permanently or
> long-term marked as unstable?
That's a policy decision that goes a step beyond just having a mechanism
in the first place, but I would say a class should be unstable if:
- Different implementations can deviate considerably from each other in
terms of ABI (e.g. std::string).
- The class represents a subject that is the focus of active research
(e.g. std::regex).
- The class is sufficiently complex that a period of refinement would be
reasonable after the initial implementation. This does not imply that
such a class can be made stable later: a stable class needs to have its
ABI set in stone from the beginning, to allow interoperability with
other implementations and other languages (e.g. std::unordered_map).
- The class can reasonably be expected to be augmented with additional
features in the future (e.g. std::thread).
In my view, the only classes that can immediately be marked as stable
are those where you can either reasonably expect that multiple
implementations will inevitably end up with an identical (or nearly
identical) ABI (e.g. std::chrono::time_point, std::pair), or that are
designed specifically for the purpose of exchanging data across public
interfaces.
I would consider this proposal to have failed in its purpose, if it
meant that every single new class had its ABI specified by the
committee. Instead I expect classes to be judged on their suitability
for having a stable implementation, and the vast majority to be
rejected. The preference should be to give implementers the freedom to
achieve the best performance possible, and that conflicts with the
desire for maximum stability.
Hans Guijt
> On Wednesday 10 July 2024 03:01:39 GMT-7 Hans via Std-Proposals wrote:
>> The focus of the paper is not on how to implement such interfaces,
>> however, it is on communicating (and enforcing) that library classes are
>> subject to change in future library revisions, and therefore not safe to
>> use in public interfaces.
>
> Can you give examples of Standard Library classes that would be permanently or
> long-term marked as unstable?
That's a policy decision that goes a step beyond just having a mechanism
in the first place, but I would say a class should be unstable if:
- Different implementations can deviate considerably from each other in
terms of ABI (e.g. std::string).
- The class represents a subject that is the focus of active research
(e.g. std::regex).
- The class is sufficiently complex that a period of refinement would be
reasonable after the initial implementation. This does not imply that
such a class can be made stable later: a stable class needs to have its
ABI set in stone from the beginning, to allow interoperability with
other implementations and other languages (e.g. std::unordered_map).
- The class can reasonably be expected to be augmented with additional
features in the future (e.g. std::thread).
In my view, the only classes that can immediately be marked as stable
are those where you can either reasonably expect that multiple
implementations will inevitably end up with an identical (or nearly
identical) ABI (e.g. std::chrono::time_point, std::pair), or that are
designed specifically for the purpose of exchanging data across public
interfaces.
I would consider this proposal to have failed in its purpose, if it
meant that every single new class had its ABI specified by the
committee. Instead I expect classes to be judged on their suitability
for having a stable implementation, and the vast majority to be
rejected. The preference should be to give implementers the freedom to
achieve the best performance possible, and that conflicts with the
desire for maximum stability.
Hans Guijt
Received on 2024-07-11 11:57:48