[libcxx-commits] [PATCH] D134473: [libc++] Keep unary_function and binary_function in C++17 for one more release

Fri Sep 23 11:38:03 PDT 2022

Mordante accepted this revision as: Mordante.
Mordante added a comment.

In D134473#3809725 <https://reviews.llvm.org/D134473#3809725>, @ldionne wrote:

> If accepted, this patch would only go towards the LLVM 15 branch. The behavior for LLVM 16 is already the way we want it.
>
> Note that I will be shipping this patch in Apple's libc++ no matter what we do here, simply because we've noticed too many failures caused by this and we need more time to address them. I think the greater community would also benefit from a 1-release grace period where we produce a deprecation warning but don't break people's code, but I can also live with the hard stance we've taken so far.

Mainly for my curiosity what is the issue to use `_LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION` at Apple?

If this is an issue for Apple, will that also be an issue for "less connected" companies? I mainly ask since I don't know how many other (large) companies are affected by this libc++ change. (I know Google likes to follow HEAD closely they are used to adapt to upstream changes quickly, other companies are probably not as agile.)

I love to deprecate things and remove cruft, but in the end libc++ should serve the needs of its customers. So if the current deprecation/removal policy is an issue, maybe we should reconsider our policy.

To me if this breaks Apple +1 to backport it for all our users.

LGTM I leave the final approval to @philnik .

================
Comment at: libcxx/docs/ReleaseNotes.rst:147
+  that this disables all deprecation warnings. Also note that per the Standard, ``unary_function``
+  and ``binary_function`` will be removed in C++17 and above starting in the next release.

----------------
This is the typical wording we use.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134473/new/

https://reviews.llvm.org/D134473