<div class="gmail_quote">On Tue, Mar 6, 2012 at 9:21 AM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:kyrtzidis@apple.com">kyrtzidis@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, to recap, the question is this, should we implement and maintain a gcc extension that was deprecated since gcc 3 ?</blockquote></div><br><div>I think you've outlined well why we shouldn't. This is a high-cost addition to Clang, and I completely agree with your assessment of that cost.</div>
<div><br></div><div>That leaves me with the question: why *should* we support this extension? I see two possible reasons, but perhaps others have better justifications. Here are my two cents. =]</div><div><br></div><div>1) There is a large body of (likely legacy) proprietary code that uses this feature, and a company is interested in having Clang support for that body of code.</div>
<div><br></div><div>2) There are enough open-source codebases still using this feature that largely open-source-based code eco-systems are likely to have this missing feature as a barrier to entry.</div><div><br></div><div>
To address these in reverse order, #2 I simply don't believe to be true. We have built a substantial amount of open source code with Clang and have not once run into this. I'm confident that it will remain untrue as GCC has also left this feature behind. I don't think there is any compelling reason to believe this extension matters for adoption of Clang.</div>
<div><br></div><div><br></div><div>On the other hand, #1 is certainly plausible. That said, it is only a *good* reason if the company with this large body of code is going to fund long-term maintenance and improvements of Clang. I think it's risky to accept such extensive changes until the long-term commitment has actually materialized. I think a branch or something similar to reduce their merge costs until we're satisfied there is a good maintenance story would be better.</div>
<div><br></div><div>-Chandler</div>