At the moment the implementation of std::format is incomplete and
there will be ABI breaking changes in the future:
- Some shortcuts were taken to get a working basic version. Resolving these shortcuts will cause ABI breaking changes. For example the storage of the formatting arguments is currently done in a simple fashion leading to inefficient memory usage. Improving this is required by the Standard. However validating the required implementation is easier with the basics of std::format working. At that point there are proper tests to guard against regressions.
- The C++ committee accepts LWG issues that contain ABI breaks. For example http://wg21.link/P2216.
As long as a Standard isn't ratified libc++ makes no promises on ABI
stability for new features. After a Standard is ratified there's no good
way for libc++ to communicate to its users a feature isn't complete yet.
This is now the case with std::format, but the same may occur in the
future with other 'monolithic' features. For example, when Networking TS
will become part of the Standard.
This is a RFC to see how we can solve this problem. It aims to:
- Make it possible to develop high quality implementations in main, while not being afraid to make ABI breaking changes to improve the implementation.
- Make it possible to work on large features in main that can't be completed in one LLVM release cycle.
- Warn users when using not Standard conforming code.
- Warn users when using ABI unstable features.
Obviously using this escape hatch isn't ideal and when possible we
should attempt to avoid it.
In theory there's a simple solution. C++ has feature test macros that
allows users to query whether a feature is complete. However it's
uncertain whether users use this macro or just try to compile the code
and if it compiles they expect it to behave properly.
The current implementation in <format> uses #error this has the
advantage that including the header gives a nice diagnostic. For other
headers it might be better to only guard certain features. For example,
when the C++ committee's ABI break only affects a single function it's
possible to only disable this function. In that case there will be no
clear diagnostic how to enable the feature.