[PATCH] D55045: Add a version of std::function that includes a few optimizations.

Kristina Brooks via Phabricator reviews at reviews.llvm.org
Fri Nov 30 21:22:14 PST 2018

kristina added a comment.

In D55045#1315541 <https://reviews.llvm.org/D55045#1315541>, @EricWF wrote:

> In D55045#1314652 <https://reviews.llvm.org/D55045#1314652>, @jsoyke wrote:
> > FWIW, I'm slightly in favor of using different headers. For example, I just realized that this change currently leaves a bunch of baggage symbols laying around that the new code won't use, it would be easier to see that kind of thing if the internals of each function were just in it's own file.
> I'm strongly against it. The harder it is to see all the implementations of a given function `f`, the harder it is to know they exist and keep them in sync. In my experience spreading these things out leads to real bugs.
> @ldionne wrote:
> > This is why I would like for us to plan on a solution that is more easily maintainable in the face of N implementations, not just 2 implementations (disregarding the C++03 implementations).
> I would like that too. but that's not a blocking issue on this review.
>  I also don't agree that we'll see more `std::function` implementations in the future. We won't. We're not going to standardize additional features to `std::function` unless they're not ABI breaking. That is, if the standard does `function` it'll won't require another version of it.
>  Maybe you were thinking about things like `std::unique_function`?
> Note that having the C++03 functions be in a separate file with no relation or interleaving with the C++11 implementation has caused plenty of bugs in the past where they diverge.

I don't see the issue with breaking ABI that's designated as unstable as long as there's some form of announcement to avoid any confusion. Fundamentally that's the entire point of having unstable ABI versions, some changes are just not really possible to make without ABI breakages, most consumers just use the stable ABI, while unstable ABI is not backwards compatible otherwise it would make a whole range of changes to `libc++` and/or Clang impossible.

  rCXX libc++



More information about the libcxx-commits mailing list