I’m working on upgrading a large internal codebase to C++20. I’ve run into many errors related to standard library removals, e.g. around std::result_of and allocator members. A lot of those errors are in third-party code which we don’t want to maintain local patches for, and while I can send upstream fixes, there’s no guarantees around if or when they’ll be accepted. We could keep third-party code on an older standard, of course, but we also have situations where first-party code uses third-party headers, and we don’t want to hold all such first-party code back either.
Using libc++ macros to re-enable the removed features in these situations (e.g. _LIBCPP_ENABLE_CXX20_REMOVED_TYPE_TRAITS) seems like a convenient solution, at least in the short-term. Before I go ahead with that though, I wanted to ask: are we planning to keep these macros around in the long-term, or are there no guarantees around when they might be removed? In other words, would I be leaving a ticking time-bomb in the codebase by doing this?
Enable _LIBCPP_ENABLE_*_REMOVED_* by default in -std=gnu++NN? is a related previous discussion for C++17, where @ldionne mentioned potentially removing support for these macros. Funnily enough, I commented on that thread at the time in favor of keeping the features removed. C++20’s removals seem to be a lot more disruptive though (at least in our codebase), and from looking at clang-tidy - Clang-Tidy Checks — Extra Clang Tools 17.0.0git documentation there don’t appear to be any automated fixes for them yet (e.g. converting from std::result_of to std::invoke_result), so the migration is a lot more work and the macros seem like a much more pragmatic solution for some cases.