Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

P2123 interfaces: A Facility to Manage ABI/API Evolution #842

Open
wg21bot opened this issue Mar 24, 2020 · 1 comment
Open

P2123 interfaces: A Facility to Manage ABI/API Evolution #842

wg21bot opened this issue Mar 24, 2020 · 1 comment
Labels
B3 - Addition EWG EWGI huge IS LEWG needs-revision

Comments

@wg21bot
Copy link
Collaborator

@wg21bot wg21bot commented Mar 24, 2020

P2123R0 interfaces: A Facility to Manage ABI/API Evolution (Hal Finkel, Tom Scogland)

@wg21bot wg21bot added EWGI LEWGI labels Mar 24, 2020
@wg21bot wg21bot added this to the 2020-telecon milestone Mar 24, 2020
@brycelelbach brycelelbach added LEWG B3 - Addition IS ready-for-library-evolution-meeting-review and removed LEWGI labels Aug 25, 2020
@jensmaurer jensmaurer modified the milestones: 2020-telecon, 2021-telecon Dec 28, 2020
@brycelelbach brycelelbach added the scheduled-for-library-evolution label Feb 24, 2021
@brycelelbach brycelelbach removed the scheduled-for-library-evolution label Mar 24, 2021
@brycelelbach brycelelbach added the scheduled-for-library-evolution label Apr 23, 2021
@brycelelbach brycelelbach added library-evolution-deferred and removed ready-for-library-evolution-meeting-review scheduled-for-library-evolution labels May 11, 2021
@brycelelbach
Copy link
Collaborator

@brycelelbach brycelelbach commented May 11, 2021

2021-05-11 ISO C++ Library Evolution Telecon

P2123R0: Interfaces

2021-05-11 Library Evolution Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Hal Finkel & Tom Scogland

Minute Taker: Inbal Levi

Start: 2021-05-11 10:08 Pacific

Motivation:

  • We want the flexibility to change the implementation details and interfaces of types in order to enhance functionality and realize performance benefits.
  • We want interface stability necessary to compose software from time.
  • C++ lacks the facilities today to do this.

"On costs" slide typo - "technical dept" should be "technical debt".

Presentation Ends, Discussion Starts: 11:00

Idea: Mechanism for globally changing the default interface version and default level of resiliency.

Idea: Mechanism for different versions to exist within a single TU, including conversion from newer version objects to older version objects.

End: 11:31

Summary

Spurred by P2123 (interfaces), we had an excellent discussion of what the Standard Library would need from a language facility for resiliency and the nature and extent of Library Evolutionary challenges relating to stability. A few of the key takeaways from the discussion are summarized below.

We need clearer definitions of the problems we are trying to solve and the techniques we plan to use to solve them. For example, it is important to clearly differentiate between:

  • Changes to the Standard that would involve changing both the API (e.g. changing semantics) and ABI,
  • Changes to the Standard that would extend the API and change the ABI (e.g. adding virtual functions), and
  • Changes to Implementations that would not change the API but would change their ABI.

It is also important for us to establish a clear understanding of the distinction between various techniques and solutions in this space:

  • Stability: Maintaining API and/or ABI across versions.
  • Interoperability: When different versions can interact with each other correctly.
  • Resiliency: Mechanisms for allowing API and/or ABI to change without breaking interoperability.

An extensive and thorough study of specific places where we could improve the Standard Library if we could change the ABI, but not API or semantics, would be valuable. In particular, such a study for std::unordered_map and std::regex would be useful.

One of the main concerns with resiliency mechanisms like those proposed in P2123 are the costs and overheads, especially in cases where resiliency is not actually required. Breaking unique_ptr's ABI so that it can be passed cheaply to functions on the stack is potentially self-defeating if the resiliency mechanism requires that a resilient unique_ptr be passed via some compiler-generated type-erased wrapper. This is a classic C++ problem - we don't want to pay for what we don't use, but sometimes that leaves us lacking what we need.

If we have a resiliency mechanism, deciding the defaults for resiliency and stability will be challenging. The status quo is the that Standard Library facilities default to non-resilient and stable. P2123 suggests the default for Standard Library facilities should be non-resilient and non-stable; not all present agreed.

If a resiliency mechanism is on by default, then developers may end up paying for it when they don't need it. If a resiliency mechanism is not on by default, then developers may fail to use resiliency mechanisms when they should, causing problems for those who need to use their code. Those who need resiliency (the users of an interface) are not necessarily the ones who decide if the interface is resilient.

Supporting multiple distinct versions of a facility that can be used within the same TU is an approach that we feel has potential. Interoperability between objects of different versions could be achieved by making the newer versions convertible to and from the older versions. Then, users would only pay the cost of resiliency (conversion) when they need to call code that expects an older version of a facility.

New language facilities that make it easier to develop and maintain multiple distinct versions of facilities could make this approach feasible and sustainable enough for use in the Standard Library. Machinery similar to what's in P2123 could be support this technique.

@brycelelbach brycelelbach added needs-revision huge and removed library-evolution-deferred labels Aug 1, 2021
@jensmaurer jensmaurer removed this from the 2021-telecon milestone Nov 12, 2021
@cor3ntin cor3ntin added the EWG label Feb 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B3 - Addition EWG EWGI huge IS LEWG needs-revision
Projects
None yet
Development

No branches or pull requests

4 participants