[libcxx-dev] Advancing libc++ Beyond C++03
Eric Fiselier via libcxx-dev
libcxx-dev at lists.llvm.org
Tue Jun 11 11:07:27 PDT 2019
On Tue, Jun 11, 2019 at 12:43 PM Louis Dionne <ldionne at apple.com> wrote:
> On Jun 10, 2019, at 16:37, Eric Fiselier via libcxx-dev <
> libcxx-dev at lists.llvm.org> wrote:
> libc++ claims to support GCC with C++03 ("G++03"), and this is a problem
> for our users.
> Our C++03 users are all using Clang. They must be. Less than 9% of the
> C++03 tests pass with GCC . No non-trivial C++ program could work.
> Attempting to support G++03 impacts our QoI considerably. Unlike Clang,
> G++03 offers almost no C++11 extensions. If we could remove all the
> fallbacks for G++03, it would mean libc++ could::
> I like the general idea and I definitely support dropping support for
> C++03 under GCC, since it is effectively unsupported today anyway.
> * Improve Correctness:
> Every `#ifdef _LIBCPP_HAS_NO_<C++11-feature>` is a bug manifest. It exists
> to admit for deviant semantics.
> * Achieve ABI stability between C++03 and C++11
> Differences between our C++03 and C++Rest branches contain ABI bugs. For
> example `std::nullptr_t` and `std::function::operator()(...)` are currently
> incompatible between C++11 and C++03, but could be fixed.
> I'd like to echo what some people said regarding breaking ABI here.
> Instead of breaking the ABI for C++11 extensions in C++03, we could also
> remove them altogether. This would be a larger change that would require a
> deprecation period for those extensions, but it might be worth it and it
> would be safer than an ABI break (because source breaks are compile-time).
> We could:
The ABI break is optional. But this option is only available to us after
we drop G++03.
We can choose to fix these ABI bugs, or we can choose to keep the ABI
Let's couch the discussion of how to fix these bugs for now.
> 1. Introduce a switch that removes C++11 extensions in C++03
> 2. Somehow flag the use of these extensions, asking users to move to C++11
> or use alternatives
> 3. After some time, toggle the switch to ON by default, removing the
> 4. After some time, remove the switch altogether
> 5. Get rid of the C++11 extensions in C++03, which are now unused
> This hinges on the feasibility of users actually moving to C++11 or using
> alternatives, and most importantly the number of impacted users. If there's
> interest, it would be possible to survey large some code bases to get a
> sense for these numbers and the feasibility of my plan.
> Eric, WDYT?
libc++ is a C++11 implementation of the standard library. We should be
envisioning a future without C++03 support.
If a C++11 extension has cost to implement, decreases QoI, doesn't have
existing users, or does not provide real benefit,
then we should consider dropping it. Some extensions I think we should
remove (on a reasonable timeline):
* `std::function`: I doubt it has many C++03 users, and we don't really
need it internally.
* `<future>`: It's a shell of the actual thing in C++03. I doubt there are
We can have a lot of really nice things for libc++ once we take the initial
step of dropping G++03.
> Either way, I would try to dissociate the two projects of dropping support
> for GCC/C++03 AND taking advantage of the freedom that gives us.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libcxx-dev