<div dir="ltr">On Tue, Jul 23, 2013 at 7:17 PM, Wang Qi <span dir="ltr"><<a href="mailto:wqking@outlook.com" target="_blank" class="cremed">wqking@outlook.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">-1.<br>
<br>
I believe there are still a lot of people using VC 2008, though I can't give the data.<br>
VC 2008 (even the express version) is enough for a lot of development, such like game development.<br>
<br>
Most likely I myself will continue using VC 2008 for at least two or more years.<br>
<br>
Unlike other C++ compiler, **Clang is not only a compiler, but also a great open source library**. An open source library should better keep lowest compiler/platform requirements, when possible.<br>
<br>
Also, seems Microsoft's development tools have quite long life and can spread into many years. For example, VC6 is not complete dead up to today... (some time ago I read on Reddit comment that somebody still needs to maintain a code base written with VC6).<br>
</blockquote><div><br></div><div>Unless someone within the community steps forward with a powerful argument to continue to support VC 2008, I'm going to make the call: we don't support it.</div><div><br></div><div>
Why? I don't actually disagree with your points, but I think there are overriding concerns:</div><div><br></div><div>1) The pragmatic fact is that we simply don't have enough contributors and active (within the community) users that use, exercise, report bugs, and provide patches to support VC2008 to credibly say we support it. The fact is that we already don't, and we won't going forward regardless of what folks say on this email thread.</div>
<div><br></div><div>2) #1 isn't a problem that it is worth it to the community to solve. That is, I would rather have the developers and members of the community working to better support more modern Windows platforms rather than this old one. So I think it is actively in our best interest to not invest in changing #1.</div>
<div><br></div><div>3) LLVM (and its subprojects) have a long history of beneficially tracking and leveraging modern aspects of C++. We want to do more of this faster, not less of it slower, because it significantly improves the cleanliness, maintainability, simplicity, and performance of our libraries. To this end, it is directly to the benefit of the project to stay as close as possible to the latest versions of the various toolchain vendors.</div>
<div><br></div><div>4) Users of LLVM that are necessarily dealing with an unchanging toolchain and environment always have the option of freezing their version of LLVM along with that environment, or working assiduously to build a sufficiently strong role within the community to both provide the necessary testing and fixes for the environment (#1 above) and overcome the burden it places on the rest of the project (#3).</div>
<div><br></div><div>At this point, I suspect we should put the subject to rest.</div></div></div></div>