[libcxx-dev] Advancing libc++ Beyond C++03

[Eric Fiselier via libcxx-dev]

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:
>
> Hello,
>
> 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 [1][2]. 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
stable.

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
> extensions
> 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
users.

We can have a lot of really nice things for libc++ once we take the initial
step of dropping G++03.

/Eric


> 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.
>
> Louis
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190611/e9b60a7b/attachment.html>