Last time we discussed this, the consensus was "I think we can survive
another year without generalized constexpr and variable templates".
Well, we did indeed survive. And it's been exactly a year! So naturally,
it only makes sense to revive this :)
There's an active conversation going on in IRC right now, and it seems like
there is more desire than there was last year.
What are the main gains from allowing C++14?
* Variable templates
* Generalized constexpr
* Return-type Deduction
* Generic Lambdas
* std::make_unique<> (the source of many build bot breakages)
What are the main gains from allowing C++17? [1]
* [[nodiscard]] attribute
* structured bindings
* constexpr-if
* guaranteed copy elision
* numerous new library types: optional, string_view, variant, byte,
* numerous new algorithms: parallel algorithms, too many to list
* Probably some more, but I just tried to hit the biggest ones.
First, it seems like if we want to enable C++14 we need GCC >= 5.
And if we want to enable C++17 we need GCC >= 7.
With that out of the way, here were some of the issues that were raised
last time:
Issue: Ubuntu 14.04 LTS is on GCC 4.8.x, and we have to support it until
end of life.
Resolution: LTS is right around the corner, in 6 more months.
Issue: Various other platforms have older GCCs as their system compiler,
and it's annoying to upgrade.
Question: Do any of these not have a port you can install? For example,
NetBSD 7 appears to have GCC 5.3 as a port, if DistroWatch is any
indication. It could be wrong though and I could also be misinterpreting
it.
Issue: If we're going to make people bootstrap a compiler, we might as well
go all the way to C++17.
Comment: I'm not opposed.
Some questions / comments of my own:
* Where is this policy about Ubuntu and LTS documented? Does this mean,
for example, that we will not be able to use C++17 until 2023 (16.04 LTS
has only GCC 5.3.1)? That seems a bit unreasonable. And there's no
guarantee that 18.04 LTS will even have GCC 7 or higher either, so it could
be 2025 or 2027.
* We've asked people in the past to build a modern toolchain. For example,
we did it with C++11 and Ubuntu 12.04 LTS. Is C++17 compelling enough to
justify this again?
* GCC 4.9 probably isn't sufficient to justify an increase for anyone, as
it lacks two of the more sought-after features of C++14 (variable templates
and generalized constexpr). So IMO we should require a bump to GCC 5 or
higher, or not at all.
* Clang 6 supports all of C++20, and it builds with only C++11, so we
shouldn't have to worry too much about the problem of needing to "daisy
chain" compilers to finally get the latest version of LLVM building.
"GCC
4.8 -> Clang 6 - > Clang ToT" should hold up through C++1z.
* While we obviously can't be tied to the versioning of every single distro
out there, some are "bigger" than others. Which are big enough that
warrant serious consideration? The ones I found are (and I did my best to
aggregate all this, but please correct me if anything is incorrect or
misrepresented):
OpenBSD - Ships with GCC 4.2.1 anyway. They are already having to
bootstrap something, so the proposal here does not change anything, because
even current LLVM doesn't compile with GCC 4.2.1
CentOS & RHEL - No version of Distro, including trunk, has GCC >= 4.8.5
(are there ports?)
Debian - Minimum version 9 for GCC >= 5 (are there ports for earlier
releases?)
Fedora - Minimum version 24 for GCC >= 5, minimum version 26 for GCC >= 7
Ubuntu - Minimum LTS 16.04 for GCC >= 5
NetBSD - Version 7 has GCC 4.8.4 by default, but contains port for 5.3.0
FreeBSD - Minimum Version 11 for GCC >= 5
So, thoughts?
[1] - Note that we'd need to wait a few more revs for MSVC before allowing
C++17, but given that it's becoming easier and easier to bump the minimum
MSVC version, I'm discounting this as a factor, as MSVC will not really be
the bottleneck in any real sense.
On Tue, Oct 4, 2016 at 2:15 PM Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
> On Oct 4, 2016, at 2:10 PM, Reid Kleckner <rnk at google.com> wrote:
>
> On Tue, Oct 4, 2016 at 11:58 AM, Mehdi Amini <mehdi.amini at
apple.com>
> wrote:
>
>>
>> On Oct 4, 2016, at 8:40 AM, Reid Kleckner via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> On Tue, Oct 4, 2016 at 8:29 AM, Zachary Turner <zturner at
google.com>
>> wrote:
>>>
>>> I ask because many of these LTS distros are notoriously slow at
updating
>>> their packages. While some people may think C++14 doesn't
provide enough
>>> bang for the buck to justify bumping to GCC 4.9, C++17 definitely
does. But
>>> at that point we're going to be talking about GCC 6.1 or 6.2,
which is
>>> going to be significantly harder unless we want to wait 5-7 years,
and I
>>> suspect people won't.
>>>
>>
>> If by "notoriously slow" you mean they don't bump their
toolchain
>> versions at all, then yeah. We just wait until the LTS release is at
>> end-of-life before dropping it.
>>
>>
>> That’s the first time I read about this policy: we support every linux
>> LTS distribution till their end-of-life? Only Ubuntu? Do you have a
pointer
>> where it is documented / discussed?
>> (Note that Ubuntu LTS is 5 years AFAIK.)
>>
>
> Sorry, I didn't mean to refer to the LTS support lifetime. I just meant
we
> support the last LTS until we can reasonably expect users to have upgraded
> to the new one. If there's an LTS release every two years, then we want
to
> keep supporting them for at least three years to give people a year to
> upgrade.
>
>
> OK, got it.
>
> Thanks for clarifying!
>
> Mehdi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171031/8d5866c1/attachment.html>