Are the ENABLE_REMOVED_FEATURES going to remain supported?

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.

I don’t think we plan to remove these macros in the foreseeable future. We have to support them in older language modes anyways, so it’s not super hard to maintain. clang-tidy checks would definitely be nice. I would of course still recommend cleaning up the code, so it won’t bite you once these extensions are removed at some point.

1 Like

I actually differ in opinion here – I think it would be nice to remove those macros in the future at some point. However, when that happens, we’ll add a release note and communicate it like we normally do, so you should have a way of knowing about the removal. So it’s fine to use these macros – we provide them for that reason – but you should also ideally try to get the external code bases moving so that eventually they are not needed anymore and your whole code base is C++17 (or whichever version) compliant, without using these libc++ extensions.

1 Like