<div dir="ltr">On 30 October 2013 23:20, Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com" target="_blank">kremenek@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">>  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>If we cannot predict how fast the MSVC++ toolchain will move, how can we commit to such a regular adoption rate of new C++ features?<br></blockquote><div></div></div><br></div><div class="gmail_extra">So, I didn't take Chandler's words that literally, but even if you do, four previous releases means 2 whole years. Given current interest from Microsoft towards C++ compatibility in their compiler, and the capacity they have of getting things done (basically, money), I'd be surprised if they'd fall behind for that long.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">In time, you could have an MSVC that lags behind more than 2 years, but by then, we could easily relax the constraints. C++ could stop evolving too fast, or it could be so fast that MS will have to keep up no matter what, who knows?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Overall, I think the current movement is to start the change, not to kill projects. As Chandler said, if there are good reasons to delay or to not support this and that feature, by all means, let us know. But if you're able to move on to newer VC versions and avoid holding everyone else back, that'd be great. I don't think anyone is trying to push anything down anyone's throats, nor will we do that in the future.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">cheers,</div><div class="gmail_extra">--renato</div></div>