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 please assign to EWG once seen by LEWG.