<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 15, 2017, at 10:45 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Nov 15, 2017 at 11:56 AM Richard Smith <<a href="mailto:richard@metafoo.co.uk" class="">richard@metafoo.co.uk</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On 15 November 2017 at 11:34, John McCall via cfe-dev <span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div dir="auto" style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><span class="m_-2227037537381691233gmail-"><div class="">On Nov 15, 2017, at 11:13 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" class="">dblaikie@gmail.com</a>> wrote:</div></span><div class=""><div dir="ltr" class=""><div class="gmail_quote"><span class="m_-2227037537381691233gmail-"><div dir="ltr" class="">On Tue, Nov 14, 2017 at 12:13 PM John McCall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div></span><span class="m_-2227037537381691233gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I don't think we'd thought about documenting this (additionally) in terms of precise edits to the standard, but that's not a bad idea.</div></div></blockquote><div class=""><br class="">Wasn't there a Clang policy about language extensions that required they be at least proposed for standardization? (I can't seem to find that anymore, but I think Doug proposed it/wrote it up at some point)<br class=""><br class="">Maybe attributes don't fall under this policy? Not sure.<br class=""></div></span></div></div></div></blockquote><div class=""><br class=""></div></div>That's a very good question. I remember us talking about that, but I don't think it ever turned into a firm policy.</div></div></blockquote><div class=""><br class=""></div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">It's in a somewhat non-obvious place on the website: <a href="http://clang.llvm.org/get_involved.html" target="_blank" class="">http://clang.llvm.org/get_involved.html</a></div></div></div></div></blockquote><div class=""><br class="">Ah, thanks! I kept getting search results listing that page & figured it was a false positive... I should've looked more closely.<br class=""><br class="">Sounds like (4) is the only sticky one - and I guess this would be partly the C++ standards committee and the Itanium ABI group. (perhaps this is worth a discussion/proposal on the latter - to avoid anything like the abi_tag difficulties (which I only have a vague sense of)?)<br class=""></div></div></div></div></blockquote><div><br class=""></div>I'm not quite sure what connection you're drawing here. In this case, I think (4) is satisfied because Apple is promising to maintain the feature, as we will have internal clients that will rely on it — although it sounds like enough other people are interested in it that that really won't be a problem.</div><div><br class=""></div><div>I think what you may be suggesting is that, if we're indeed going to revise Clang's policy about features, we should include a codicil that encourages people to seek standardization of any new Clang vendor extensions when that's reasonably possible. In practice, the committees will not standardize the Clang feature, they'll standardize their own hopefully-similar feature, but it's still useful to seek standardization. This is closely related to Richard's point about trying to ensure that new features don't drive fragmentation.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">Mostly I'm just want to make sure we hold ourselves to a similar standard than we expect from everyone else - rather than using the rules as a way to keep people out while not necessarily meeting the same bar ourselves. & this seems like a good chance to reflect on the rules, see if they do/still fit, etc. Sounds like they mostly do.<br class=""><br class="">Don't mean to bog anything down in bureaucracy or anything.<br class=""></div></div></div></div></blockquote><div><br class=""></div>No, you're absolutely right to bring it up.</div><div><br class=""></div><div>Should I draft a revision to the policy? Any other initial commentary before I do?</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class="">- Dave<br class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div dir="auto" style="word-wrap:break-word" class=""> I think the important points about language features are:<div class=""><br class=""></div><div class="">1. We don't want to take a feature that we don't like the design of unless we're forced to by a language standard. We're allowed to be opinionated about language design! Required, even.</div><div class=""><br class=""></div><div class=""><div class="">2. We don't want to take a feature that's poorly-specified (again, unless we're forced to by a language standard :)). The specification doesn't have to be expressed in terms of precise edits to a standard — among other things, this would often be really annoying, since a lot of features are intended to apply in both C and C++, and they may have implications for other extensions like ObjC/OpenMP/whatever — but it should be at a point where such edits are reasonably extrapolable. I wouldn't say that it needs to be something that we can imagine an actual standards committee taking, since there are a lot of reasons a committee might reject a feature that don't necessarily imply a lack of quality; also, this would be rather inconsistent of us, since we've certainly taken features in the past that I'm not sure have much chance of standardization.</div></div><div class=""><br class=""></div><div class="">3. We want to be very cautious about accepting new language syntax because it could infringe on future language evolution. This is one place where attribute-only features have a substantial advantage.</div><div class=""><br class=""></div><div class="">4. We want major language features to be maintained. The concern here grows with the amount of code contributed and how tightly it needs to be integrated with the rest of the compiler. This is one of those area where life is not really fair, because we can't realistically assume that any single contributor is going to be able to commit to maintaining a feature the same way that an organization can. For example, I personally have a long history of contributing to Clang, and I think the language designs I've contributed have been relatively good — but if I proposed a language feature on my own behalf, without any commitment from Apple or anyone else to continue maintaining that contribution if e.g. I got hit by a bus, I'm not sure it would be reasonable for the project to accept my proposal.</div><div class=""><br class=""></div><div class="">And implicit in all of these is that the feature ought to be "open-source" — if you're going to propose a novel, non-standard feature, you need to be willing to accept feedback about both the specification and its basic design, and it really shouldn't depend on anything proprietary like a closed-source runtime library. We're allowed as a project to be opinionated about this sort of thing, too.</div><div class=""><br class=""></div><div class="">But I think if we like the feature, and we like its specification, and we don't think it infringes on language evolution, and we have strong reason to think it's going to be maintained, we don't need to hew tightly to a "no new features" mandate.</div></div></div></blockquote><div class=""><br class=""></div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">That seems essentially reasonable to me. We also need to be cognizant of the possibility of fracturing the developer community if our extensions fundamentally change the way that code is written. (Which is not the same as saying we can't have such extensions, just that they need to be especially welll-considered, and we should have a very good reason if we're not attempting to standardize them. Clang's header modules support falls somewhat into this category.)</div><div class=""><br class=""></div><div class="">Attribute-based features don't get an automatic pass, but by their nature they're much more likely to meet these criteria.</div></div></div></div>
</blockquote></div></div>
</div></blockquote></div><br class=""></body></html>