<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 11, 2019 at 1:01 PM James Y Knight <<a href="mailto:jyknight@google.com">jyknight@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Nov 11, 2019 at 3:03 PM David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote: <br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>I think that'd still be a pretty hard sell - Clang's APIs and AST are volatile & intentionally so. People writing against the Clang APIs themselves with things like clang-tidy are aware of that. If we sold this as a feature to general C++ users, I don't think there would be a way to sufficiently communicate how volatile this will be - and end up backing ourselves into a corner & limiting the ability to change Clang.<br></div></div></div></blockquote><div><br></div><div>Does Clang's AST API _need_ to be unstable in order to keep up with language changes, or is it just a convenience?</div></div></div></blockquote><div><br></div><div>I imagine with sufficient heroics the AST could be maintained for a particular version - and /probably/ version-over-version (so the C++23 AST was backwards compatible with the C++20 AST, etc). In the same way that the language itself is mostly backwards compatible version over version.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> Is this concern indicative of problems that a standardized AST API would also have, or is unique to Clang's current API?</div></div></div></blockquote><div><br>The concern is mostly indicative of a very high fidelity API - the lower level/more bare the API, the more brittle it'll be to changes (both refactoring improvements to Clang, and necessary changes to accommodate new language features). Standardizing something a little higher level could provide a lot more flexibility under the hood.<br> </div></div></div>