[llvm-dev] Using C++14 code in LLVM

[Justin Bogner via llvm-dev]

Zachary Turner <zturner at google.com> writes:
> On Tue, Oct 31, 2017 at 3:19 PM Justin Bogner <mail at justinbogner.com> wrote:
>
>> Zachary Turner <zturner at google.com> writes:
>>
>> > If 3 months later we started requiring C++17, someone could build clang 6
>> > with the system compiler and then build Clang ToT.
>> >
>> > If 3 months later we started requiring C++20, someone could still build
>> > clang 6 with the system compiler and then build Clang ToT.
>> >
>> > Every relaxation of the kind of code we can use in LLVM does not
>> > necessitate an extra hop in the bootstrapping process, because existing
>> > versions of clang can already compile through C++20.
>>
>> I hate to exaggerate, but this sounds almost like an argument for using
>> new C++ features the day after we implement them. There obviously has to
>> be some balance here.
>>
>
> Someone could probably use that line of reasoning to argue for using new
> features immediately after implementing them, but that someone wouldn't be
> me :)
>
> In any case, the point was simply to illustrate that, in general, you do
> not need to add a hop to the bootstrapping process every time you bump the
> language standard.  C++20 is 4-6 years out before we're even discussing it

Given that we're discussing moving to c++17 in 2017, less than 2 months
after we released a compiler that even accepts the flag for c++17, I
don't see why we wouldn't be discussing c++20 for "4 to 6 years". If
we're honestly considering c++17 now, we'll be honestly considering
c++20 in 2020.

If we do want to adopt a policy where we start using a new standard the
year it's approved, I think we need to be realistic about our
expectations on how we'll need to bootstrap it.

> will probably be irrelevant by that time.
>
> For C++14 and C++17 though, I think the argument still holds.  System
> Compiler -> {GCC 7 or Clang 5-6} -> ToT
>
> should require only 1 hop regardless of language standard, and that covers
> us for quite a while.

For c++14 I'm significantly less concerned policy-wise, though I'm not
personally convinced the productivity improvements we'll get from moving
to c++14 are really worth the churn.