<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Well then for any such "volatile" stuff you’d either CLANG_NO_REFLECT it or define a CLANG_RELFECT_VOLATILE so that you’d get always get a warning if it was used.<div class=""><br class=""></div><div class="">Surely a full parallel reflection property processing system to do such filtering is going to require more maintenance than anything we’re talking about here.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 11, 2019, at 5:25 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div dir="ltr" class="gmail_attr">On Mon, Nov 11, 2019 at 2:08 PM David Rector <<a href="mailto:davrec@gmail.com" class="">davrec@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 11, 2019, at 4:09 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" class="">dblaikie@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><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" target="_blank" class="">jyknight@google.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div dir="ltr" class="">On Mon, Nov 11, 2019 at 3:03 PM David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote: <br class=""></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_quote"><div class="">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 class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_quote"><div class="">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 class=""><br class="">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.</div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""> </div></div></div></div></blockquote><br class="">Volatility issues could be managed. E.g. I’ve already implem’d so that CLANG_NO_REFLECT turns off reflection for any AST public const method or field — but note that it is a crutch; any public const method is either a) eventually going to be asked to be reflected or b) probably shouldn’t be a public const method.</div></div></blockquote><div class=""><br class=""></div><div class="">Having something be "public" within Clang's codebase and users of Clang's APIs that are explicitly documented as volatile is quite different from it being public across significant amounts of end-user C++ code.<br class=""><br class="">It makes a fair bit of sense for a lot of things to be public within the former scope that aren't suitable to be public within the latter scope.<br class=""><br class="">The goal is that people may ask for (a) but we may reasonably push back and say that that level of fidelity maybe isn't worth the maintenance burden to all C++ compilers indefinitely into the future.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class=""> (Reflection is an opportunity to look in the mirror — better to hit the gym than to design a funhouse mirror to fix the issue.)</div><div class=""><div class=""><br class=""></div><div class="">I imagine Other AST attributes — e.g. CLANG_REFLECT_DEPRECATED — could be defined so that the tool generates warnings and fixits whenever they are used.</div></div></div></blockquote><div class=""><br class="">Historically the C++ standard hasn't been terribly open to significant deprecation/feature removal - it's probably not practical to plan on a reflection API that would need that to maintain... maintainability. </div></div></div></blockquote></div><br class=""></div></body></html>