[cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

[Chandler Carruth]

On Mon, Oct 28, 2013 at 6:07 PM, "C. Bergström" <cbergstrom at pathscale.com>wrote:

> On 10/29/13 07:27 AM, Chandler Carruth wrote:
>
>  On Mon, Oct 28, 2013 at 5:06 PM, "C. Bergström" <cbergstrom at pathscale.com<mailto:
>> cbergstrom at pathscale.**com <cbergstrom at pathscale.com>>> wrote:
>>
>>     fuzzy://How much "heads up"
>>
>>
>> One full release cycle, so approximately 6 months before a release
>>
> If it's 3-6 months from *today* before something hits clang svn trunk that
> should be enough time to address any problems.


No, it's 1 month, maybe 2 before something hits trunk, and over 6 months
before something hits a release.


> (Such as testing libc++ more extensively and or sending any patches if
> necessary) I don't know the 3.4 release timeline and if you want to adopt
> this immediately after that has branched. [My other points below can be
> ignored if this is true]
>

I don't think there is any need for further testing. Others have reported
no issues here, so I suspect the problem is on your end and something you
can sort out.


>
>
>> Some notable features we would get to use:
>>
>> - r-value references, move semantics, etc
>> - auto
>> - range for loops
>> - lambdas
>> - static_assert
>> - nullptr
>> - std::unique_ptr, std::tuple, some other nice library stuff
>>
>>
>>  I'd love to see/review an updated style guideline before anything hits
> SVN trunk so that it's super clear on what's allowed. Maybe I'm too
> conservative, but it's still fuzzy on how using some of those features
> would benefit the compiler internally.
>
> Usage of c++11 code in applications (chrome) and the compiler are 2
> different worlds to me. You ask if I write c++11 codes - No, but
> increasingly I do see it being used in production and forced to deal with
> it. Sometimes it makes sense and sometimes I think meh or wtf -
>

You're certainly welcome to your opinions. =] Others have consistently
expressed the other opinion, and my priority is toward those actively
contributing patches and reviews to the project. Of those, there has been a
widespread and strong support for adopting C++11 features. If you see code
being committed during code review which has questionable value, you should
provide the review and articulate there why the C++98 construction would be
preferable.



>  It also would have the benefit of removing divergence between LLVM
>> sub-projects already using C++11 features
>>
> Which sub-projects would this benefit?


As has been mentioned repeatedly, LLD.


>
>
>> There is increasing pressure for LLVM to make use of new C++ language and
>> library features.
>>
> pressure from where? (sub-projects, google.. ?)


Those contributing patches, reviewing patches, and writing the code that
makes up LLVM's various projects.


>
>
>> I have historically been more conservative on this topic, but listening
>> to many people and looking at some of the C++ features we are missing
>>
> watercooler or mailing list?


All of the above. There have been plenty of discussions on the mailing
lists and it patch review that ended up being "yes, it would be great if we
could do that, but we don't have X feature in C++11, so we have to do this
ugly thing over here".


> These days, this list seems increasingly worth the cost of forcing users
>> to get a modern toolchain onto their systems.
>>
>>  I'm all for modern toolchains, but a modern toolchain requirement and
> depending on c++11 features are independent issues. You could make a policy
> that ______ doesn't care about building and supporting gcc-3.x on ________
> old ${platform} - I'm cool with that, but it doesn't mean we must rely on
> c++11 in the process.
>

Nor have I indicated we must rely on C++11. Rather, I'm saying that there
is a strong desire to have C++11, and doing so requires moving forward in
terms of the toolchains we support.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131029/8df80b63/attachment.html>