<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Oct 27, 2013 at 11:18 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank" class="cremed">clattner@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sun, Oct 27, 2013 at 2:23 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="cremed">chandlerc@google.com</a>> wrote:> Concrete long term proposal:<br>
</div><div class="im">
><br>
> We support building with C++ toolchains which were released and widely available on their respective target platforms at least 2 years prior to the next 6-month-cycle release. Immediately after each branch of a release, mainline can move the bar forward by 6 months. Thus, each release should build with the four previous releases.<br>

<br>
</div>I don't think it makes sense to have a hard policy like this.  It is fine to have a goal that allows us to continue picking up new features over time, but I think each such change will have to be discussed (at length) with the specifics of which interesting host configurations we would be dropping.<br>
</blockquote><div><br></div><div>I didn't really intend to indicate this would be a hard policy, more that it would be the guideline. Part of the idea is that after each release branch is cut we could evaluate what a reasonable baseline would look like.</div>
<div><br></div><div>I do think that 2 years is a good guideline, in part because two of the three toolchains which impact us most already use time-driven release cycles.</div><div><br></div><div>My hope is that we could *strive* for no more than two years of support for older toolchains as a way to push ourselves to not let this slip.</div>
<div><br></div><div><br></div><div>An obvious other input to this decision would be exactly what Benjamin brought up: we should look at what toolchain versions various OSes are shipping with. However, I think the diversity of OS is too broad to be easily explained in our getting started docs, etc. I would rather use the OS situation to inform the particular versions of each toolchain that we try to support, but to word the decision in terms of the toolchain versions.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> One short term caveat: Windows is special.<br></div><div class="im">
<br>
</div>I don't see how it is special.  We should just look at all of the compilers we need to support, and factor that set in.  We should continue to increment the baseline compilers over time, but a global "two year old compilers only" policy doesn't make sense to me.  I also think that windows will be the lowest bar anyway.<br>
</blockquote><div><br></div><div>See above. I'm not interested in a hard policy. I think MSVC will end up being special because we may realistically want a *narrower* set of toolchains supported there given both the rapid advances of MSVC in the last year, and the rapid changes to Clang and LLVM's role on that platform.</div>
<div><br></div><div>(And note, I misspoke previously, clearly MinGW is just GCC, I'm talking about MSVC here)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">> Now for the carrot: if we go with this plan, then immediately after branching for 3.4,  we would be able to use the vast majority of C++11 features, targeting the following as the oldest toolchains supported through the 3.5 release timeframe:<br>

><br>
> GCC 4.7<br>
> Clang 3.1<br>
> VS 2012<br>
<br>
</div>This seems overly aggressive to me.  Why not start by baselining at VC++ 2010, and bump up everything else to match?  That would give us some basic C++'11 features for 3.4, then we could bump it up to VS 2012 in 3.5 if that goes well.<br>
</blockquote><div><br></div><div>As others have pointed out, our baseline is already VS 2010, but our C++11 features have been held back by concern over GCC. I think the time frame is right to jump all the way to GCC 4.7 as the target for our 3.5 release, and would like to bump VS to 2012 at the same time if at all possible.</div>
<div><br></div><div>This isn't just a bump either, it brings things that I think will be very useful:</div><div>- Fixed semantics for r-value references that is relevant to using move semantics broadly in LLVM</div><div>
- Range-based for loops, because as much as people say it "just reduces boiler plate", omg it is so much nicer</div><div>- better concurrency support, notably we may be able to use the standard atomics library (with some testing and restrictions) which have compiler assistance behind them.</div>
</div></div></div>