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

[Justin Bogner via llvm-dev]

JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> writes:
>> On May 10, 2018, at 11:35 AM, Zachary Turner <zturner at google.com> wrote:
>> 
>> If it's the only thing we can agree then I'll take it, but I just
>> worry that 3 years from now we're going to start another 3 year
>> discussion, so that any actual move to C++17 would end up taking
>> double the time.
>
> Such a fatalistic view, let’s trust ourselves to be better next time ;-)
> But seriously: we can learn from moving to C++14, and use what we’ve
> learned to move to C++17 faster next time. Also consider the code
> churn we’ll encounter as we fix incompatibilities with C++11 / C++14,
> drop unnecessary code, upgrade various uses, that will happen
> regardless of moving to C++17 and will take a little while to
> occur. There would be more of that type of churn if we went straight
> to C++17.
>
>
>> Are the issues specific to C++17 additions to the standard library?
>> What if you allow C++17 language features but not C++17 library
>> features?  I'm guessing this is too simple though and isn't
>> sufficient to avoid the problems (which I don't know anything about,
>> so you'll have to enlighten me)?
>
> Mostly library so far, yes, but the GCC 6 support for C++17 language
> isn’t great either:
>
>  - New auto rules for direct-list-initialization		
>  - static_assert with no message
>  - typename in a template template parameter
>  - Nested namespace definition
>  - Attributes for namespaces and enumerators
>  - u8 character literals
>  - Allow constant evaluation for all non-type template arguments
>  - Fold Expressions
>  - Unary fold expressions and empty parameter packs
>  - __has_include in preprocessor conditional
>  - Differing begin and end types in range-based for\
>
> From: https://en.cppreference.com/w/cpp/compiler_support
> <https://en.cppreference.com/w/cpp/compiler_support>
>
> The only thing that’s really nice are fold expressions, and I hope
> they’re not buggy in GCC 6.
>
> Otherwise the list is missing a good amount for C++17 language
> features, and brings up the discussion of which GCC version is the
> minimum we mandate. I’d rather avoid that discussion. Let’s assume GCC
> 6, if we get 7 then great, but it doesn’t matter if we stick to C++14.

FWIW I still think (1) it's too early to upgrade to c++17, and (2) we
don't get enough from c++14 for the upgrade to really be worth it. See
the thread from a few months ago for more detail:

  http://lists.llvm.org/pipermail/llvm-dev/2017-October/118683.html