C++17 is here. Should we use it?

# JF Bastien (2 years ago)

Hello WebKilters,

Our Chrome-y friends are considering the use of C++14 groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ. I have to say that C++14 in WebKit has been quite amazing, and we should consider using C++17: it has many wonderful new things tvaneerd/cpp17_in_TTs/blob/master/ALL_IN_ONE.md, some of which we already use through WTF’s re-implementation of library features. By now (table as witness en.cppreference.com/w/cpp/compiler_support) most C++17 languages features are in clang and GCC, and MSVC isn’t doing too bad either. Language things can just come through WTF if we really want them.

So how about it?

JF

Contact us to advertise here
# Yusuke SUZUKI (2 years ago)

I really like C++17, if with initializer is super great. Awesome constexpr lambda and if. And std::optional and std::variant...

However, IIRC, WebKitGTK+ needs to support some old compilers. The current GCC support is 5.0.0, which is recently upgraded. bugs.webkit.org/show_bug.cgi?id=174155

Possibly, mcatanzaro and clopez know much about WebKitGTK+ compiler dependencies.

# Michael Catanzaro (2 years ago)

On Fri, Aug 4, 2017 at 3:48 PM, Yusuke SUZUKI <utatane.tea at gmail.com>

wrote:

Possibly, mcatanzaro and clopez know much about WebKitGTK+ compiler dependencies.

As a result of the C++14 discussion on this list a few months ago, we relaxed our dependencies policy [1] to allow upgrading to GCC 5 one year earlier than planned, to the displeasure of some of our distributors who now have to build a custom compiler as part of their WebKit builds. We would prefer not to relax the policy further.

Our current schedule looks like:

  • GCC 6 could be required in April 2018 (next Ubuntu LTS release)
  • GCC 7 (required for C++17) could be required likely late in 2019 (next Debian stable release)

Is that acceptable for Apple?

Michael

[1] trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy

# JF Bastien (a year ago)

Hello again WebKitten!

April 2018 is fast approaching, which means that we might be able to require GCC 6 and all the great C++17 features that’ll come with it. So what say you? From C++17 it looks like we wouldn’t get quite a few things, but we’d be able to use a few nice things (see the table en.cppreference.com/w/cpp/compiler_support).

JF

# Michael Catanzaro (a year ago)

On Fri, Mar 23, 2018 at 4:32 PM, JF Bastien <jfbastien at apple.com> wrote:

Hello again WebKitten!

April 2018 is fast approaching, which means that we might be able to require GCC 6 and all the great C++17 features that’ll come with it. So what say you? From C++17 it looks like we wouldn’t get quite a few things, but we’d be able to use a few nice things (see the table).

JF

Hi,

I've been asking around, and it sounds like this will be a significant inconvenience for some Igalia projects where upgrading the compiler is a bit difficult, but everyone agrees the time specified in the dependencies policy (the next Ubuntu LTS release) is fast approaching, and that the policy is a good compromise. It looks like the next Ubuntu release is due on April 26 [1], one month from today, so we should be good to require GCC 6 at that time. Sound good?

Michael

[1] wiki.ubuntu.com/BionicBeaver/ReleaseSchedule

# JF Bastien (a year ago)

On Mar 26, 2018, at 07:38, Michael Catanzaro <mcatanzaro at igalia.com> wrote:

On Fri, Mar 23, 2018 at 4:32 PM, JF Bastien <jfbastien at apple.com> wrote:

Hello again WebKitten!

April 2018 is fast approaching, which means that we might be able to require GCC 6 and all the great C++17 features that´ll come with it. So what say you? From C++17 it looks like we wouldn´t get quite a few things, but we´d be able to use a few nice things (see the table en.cppreference.com/w/cpp/compiler_support).

JF

Hi,

I've been asking around, and it sounds like this will be a significant inconvenience for some Igalia projects where upgrading the compiler is a bit difficult, but everyone agrees the time specified in the dependencies policy (the next Ubuntu LTS release) is fast approaching, and that the policy is a good compromise. It looks like the next Ubuntu release is due on April 26 [1], one month from today, so we should be good to require GCC 6 at that time. Sound good?

Michael

[1] wiki.ubuntu.com/BionicBeaver/ReleaseSchedule, wiki.ubuntu.com/BionicBeaver/ReleaseSchedule

Thanks! I’d be very happy to bring a few new features in! Let’s see if anyone else wants to chime in by then :-)

# Alex Christensen (24 days ago)

It’s always fun to reply to two year old emails.

I would like to have a plan to start using and requiring C++17 in WebKit. Based on my minimal research, I believe that DebianBuster is frozen but not yet released. Is there something we are still waiting for, or could we begin making the switch?

# Alex Christensen (21 days ago)

I’m interpreting the lack of objection to mean there is no reason not to proceed with bugs.webkit.org/show_bug.cgi?id=197131 once I get everything working nicely.

# Konstantin Tokarev (21 days ago)

20.04.2019, 01:16, "Alex Christensen" <achristensen at apple.com>:

It’s always fun to reply to two year old emails.

I would like to have a plan to start using and requiring C++17 in WebKit. Based on my minimal research, I believe that DebianBuster is frozen but not yet released. Is there something we are still waiting for, or could we begin making the switch?

[1] says: "we support each major Debian version until one year after the release of the next major version"

Given that Buster is not released yet, bumping GCC requirement to 7 seems to be premature.

OTOH, GCC 6 has partial support of C++17 [2,3] under -std=c++1z, which might be sufficient for now.

[1] trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy [2] gcc.gnu.org/projects/cxx-status.html#cxx17 [3] gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017

# Michael Catanzaro (10 days ago)

On Tue, Apr 23, 2019 at 10:50 AM, Konstantin Tokarev

<annulen at yandex.ru> wrote:

[1] says: "we support each major Debian version until one year after the release of the next major version"

Given that Buster is not released yet, bumping GCC requirement to 7 seems to be premature.

The dependencies policy states that toolchains are only supported until the release of the next major version, but yes, the Debian Buster release has not happened yet and is likely still several months away.

Still, it's been two weeks since Alex proposed to require GCC 7, and no objections have been posted to this list. After talking with Berto, I've confirmed that Debian is OK with building packages with Clang if need be, and if it works for Debian it should work for Ubuntu as well. So instead of requiring that WebKit build with the default system compiler, we can just require that it build with some system compiler.

We do need to support the distro's libstdc++ for the full year after the next release, though, as otherwise it won't be possible for the distros to continue to update WebKit. The current policy language regarding toolchains does not account for that. So I'd like to simplify this by saying that we support some system compiler for one year after the release of the next major version, but not necessarily the default system compiler.

My proposed changes to trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy are:

Keep:

""" Our dependencies policy is simple:

  • We support each major Debian version until one year after the release of the next major version.
  • We support each Ubuntu LTS until one year after the release of the next Ubuntu LTS. """

Then replace all the rest with:

""" During the support period, we intend for WebKit to remain buildable on these distributions using some system-provided compiler, not necessarily the default system compiler, and with the default system libstdc++. The purpose of this policy is to ensure distributions can provide updated versions of WebKit during the support period to ensure users receive security updates. """

Now, those changes would imply that we can require GCC 7 now, but not yet libstdc++ 7, since the policy would normally require that we continue supporting Debian Stretch for another year. But we can make a one-time decision to ignore that, because Stretch isn't receiving WebKit security updates, so it doesn't really matter. Now, good news: Debian Buster will be the first version to receive WebKit updates, thanks to our promises of stable dependencies and Ubuntu's success with providing WebKit updates during the last two years. The goal of providing security updates to Debian will fail if we drop support for Debian's libstdc++ within their primary security support period (one year after release of the next version), though; that would be a major setback. So my proposed change makes it easier to increase our GCC requirement (if the old distros can build with old clang, then we can do it), but harder to increase our libstdc++ requirement (need to wait one additional year to do so).

The proposed future would look like this:

  • Imminently: require GCC 7 and libstdc++ 7
  • April 2021: require libstdc++ 8 (one year after Ubuntu 20.04 release)
  • Late 2021 or early 2022: require libstdc++ 9 (one year after the successor to Debian Buster is released)

Then we can require new GCCs whenever we want, as long as the old clangs suffice. Ubuntu 18.04 has clang 6.0, for instance, so as long as clang 6.0 works, then we can advance to GCC 8 whenever desired. Debian Buster has clang 7.0, so come April 2021 we'd be able to require that. But one of the system compilers would need to work for the full three years. Then the long support period for libstdc++ is required to make sure our users don't get cut off from security updates. There's no way around that: if we want to require newer standard libraries, then our users will no longer receive updates, period.

Is this OK?

OTOH, GCC 6 has partial support of C++17 [2,3] under -std=c++1z, which might be sufficient for now.

Beware that GCC 9, released yesterday, is the first version in which C++ 17 support is no longer experimental. Most things should work in GCC/libstdc++ 7, but as always, there's going to be bugs that we're going to have to live with.

Michael

# Michael Catanzaro (7 days ago)

Since there were no objections, I've updated the policy on the wiki:

trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy, trac.webkit.org/wiki/WebKitGTK/GCCRequirement

Michael

# Konstantin Tokarev (6 days ago)

07.05.2019, 16:53, "Michael Catanzaro" <mcatanzaro at igalia.com>:

Since there were no objections, I've updated the policy on the wiki:

trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy, trac.webkit.org/wiki/WebKitGTK/GCCRequirement

Note that since we have to support libstdc++ 6.x, most of C++17 standard library features () should be disallowed. Those include std::filesystem, std::string_view, etc. Core language features should be fine.

# Alex Christensen (6 days ago)

If you have a minimum-requirements system that you want to keep building, put build infrastructure on build.webkit.org so we can see when things break.

We plan to actively push to update requirements again in 2021.

# Michael Catanzaro (6 days ago)

On Tue, May 7, 2019 at 1:53 PM, Alex Christensen

<achristensen at apple.com> wrote:

If you have a minimum-requirements system that you want to keep building, put build infrastructure on build.webkit.org so we can see when things break.

We already have stable release bots to test the lowest-supported configurations, but most developers should only ever need to worry about EWS, as always.

Michael

# Michael Catanzaro (6 days ago)

On Tue, May 7, 2019 at 1:46 PM, Konstantin Tokarev <annulen at yandex.ru>

wrote:

Note that since we have to support libstdc++ 6.x, most of C++17 standard library features () should be disallowed. Those include std::filesystem, std::string_view, etc. Core language features should be fine.

With my suggested one-time exception to drop support for Debian Stretch early due to lack of security updates there, I think it's perfectly fine to require libstdc++ 7 now. Igalia's EWS and stable release bots might need to be updated, but this is not a problem.

Michael

# Yusuke Suzuki (3 days ago)

Cool! So,

  1. We can use GCC 7
  2. We can use libstdc++7

Is my understanding correct? Basically, this means that we can use cool C++17 features super aggressively :)

Best

# Konstantin Tokarev (3 days ago)

11.05.2019, 02:47, "Yusuke Suzuki" <ysuzuki at apple.com>:

Cool! So,

  1. We can use GCC 7
  2. We can use libstdc++7

Is my understanding correct? Basically, this means that we can use cool C++17 features super aggressively :)

Not so aggressively with library features, a few of them require libstdc++ 8 or even 9[1]. However, there is portable implementation of std::filesystem [2] which we could use as a "polyfill" if needed.

[1] gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017 [2] gulrak/filesystem

# Michael Catanzaro (3 days ago)

On Fri, May 10, 2019 at 6:47 PM, Yusuke Suzuki <ysuzuki at apple.com>

wrote:

  1. We can use GCC 7
  2. We can use libstdc++7

Is my understanding correct? Basically, this means that we can use cool C++17 features super aggressively :)

I would say you can use cool C++ 17 features cautiously, enjoying those features when they work, and expecting the possibility of libstdc++7 bugs causing them to not work.

I think our EWS bots are not yet on GCC 7, but that should be addressed soon.

Michael

Want more features?

Request early access to our private beta of readable email premium.