<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 28, 2013 at 6:07 PM, "C. Bergström" <span dir="ltr"><<a href="mailto:cbergstrom@pathscale.com" target="_blank" class="cremed">cbergstrom@pathscale.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/29/13 07:27 AM, Chandler Carruth wrote:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Oct 28, 2013 at 5:06 PM, "C. Bergström" <<a href="mailto:cbergstrom@pathscale.com" target="_blank" class="cremed">cbergstrom@pathscale.com</a> <mailto:<a href="mailto:cbergstrom@pathscale.com" target="_blank" class="cremed">cbergstrom@pathscale.<u></u>com</a>>> wrote:<br>

<br>
    fuzzy://How much "heads up"<br>
<br>
<br>
One full release cycle, so approximately 6 months before a release<br>
</blockquote></div>
If it's 3-6 months from *today* before something hits clang svn trunk that should be enough time to address any problems.</blockquote><div><br></div><div>No, it's 1 month, maybe 2 before something hits trunk, and over 6 months before something hits a release.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> (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]<br>
</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Some notable features we would get to use:<br>
<br>
- r-value references, move semantics, etc<br>
- auto<br>
- range for loops<br>
- lambdas<br>
- static_assert<br>
- nullptr<br>
- std::unique_ptr, std::tuple, some other nice library stuff<br>
<br>
<br>
</blockquote></div>
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.<br>

<br>
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 -<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It also would have the benefit of removing divergence between LLVM sub-projects already using C++11 features<br>
</blockquote></div>
Which sub-projects would this benefit?</blockquote><div><br></div><div>As has been mentioned repeatedly, LLD.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There is increasing pressure for LLVM to make use of new C++ language and library features.<br>
</blockquote></div>
pressure from where? (sub-projects, google.. ?)</blockquote><div><br></div><div>Those contributing patches, reviewing patches, and writing the code that makes up LLVM's various projects.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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<br>
</blockquote></div>
watercooler or mailing list?</blockquote><div><br></div><div>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".</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

These days, this list seems increasingly worth the cost of forcing users to get a modern toolchain onto their systems.<br>
<br>
</blockquote></div>
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.<br>
</blockquote><div><br></div><div>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.</div>
</div></div></div>