<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=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Great example. One nice thing about clang-specific reflection, distinct from the standards effort, is that there are already a lot of clang tools out there that do what we want…and making them constexpr metafunctions is mostly a matter of copying and pasting, since the syntax is the same. E.g. I see at least one autodiff clang tool out there. </div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Substitute auto/constexpr auto for most of the variable types, use constexpr containers (I’ve implem’d vector, set, and map) in place of any heap allocations, use __queue_metaparse("…") instead of outputstream << "…", and…sure to be other constexpr-related issues, but we’d get them figured out. (Probably need more constexpr const char *-altering functions, a la Andrew’s excellent __concatenate(…) built in function, since std::string would be out.)</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">The ultimate litmus test might be whether a metafunction can be written to turn any clang tool into a metafunction…</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Dave<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 13, 2019, at 3:42 PM, Herb Sutter <<a href="mailto:herb.sutter@gmail.com" class="">herb.sutter@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; 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 style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I don’t want to weigh in for/against any particular Clang proposal, but FWIW regarding this:<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">> Not all demands must be satisfied.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">True, but in this case…<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">> Other languages (I'm looking at Java) have reflection without expression reflection<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">… IMO we already know that we will need statement and expression reflection, to enable uses like autodiff. For example, in the ML field I’ve encountered C++ developers who would prefer to use C++ because of its AOT compilation performance, but who of have switched to other languages such as Julia primarily because of compile-time autodiff (and more generally for the broader class of AI/ML transformations that includes autodiff) where today in C++ doing it by hand-coding the derivative function greatly slows down the experimentation phase of an ML project… which otherwise would actually be faster with AOT C++.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">At least one of the proof-of-concept C++ reflection implementations (Circle) already support statement/expression reflection and autodiff.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">For statements and expressions, my impression is that reflection is pretty straightforward to specify (here’s another meta::info API) and the primary thing to watch for is that the current proposals for injection (generated code, generative programming) will extend well to statements and expressions, again using autodiff as a litmus test example of what we want to be able to express.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Herb<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="border-style: none none none solid; border-left-width: 1.5pt; border-left-color: blue; padding: 0in 0in 0in 4pt;" class=""><div class=""><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(225, 225, 225); padding: 3pt 0in 0in;" class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class="">From:</b><span class="Apple-converted-space"> </span>cfe-dev <<a href="mailto:cfe-dev-bounces@lists.llvm.org" class="">cfe-dev-bounces@lists.llvm.org</a>><span class="Apple-converted-space"> </span><b class="">On Behalf Of<span class="Apple-converted-space"> </span></b>David Blaikie via cfe-dev<br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Tuesday, November 12, 2019 11:42 AM<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>David Rector <<a href="mailto:davrec@gmail.com" class="">davrec@gmail.com</a>><br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span>Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [cfe-dev] Reflection/metaparsing implem<o:p class=""></o:p></div></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">On Tue, Nov 12, 2019 at 6:04 AM David Rector <<a href="mailto:davrec@gmail.com" style="color: purple; text-decoration: underline;" class="">davrec@gmail.com</a>> wrote:<o:p class=""></o:p></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;" class="" type="cite"><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Fair enough. <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">As I say in my readme, I recommend those who need full reflection facilities — up to their class templates, down to the individual IfStmts etc. in their function defs — to use my implementation and simply isolate dependencies on future standards into their own helper functions. You can do everything now! No need to complain to or pressure Andrew (who has done some extraordinary work by the way) about what isn’t yet reflected.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">*Eventually* the standard will support reflecting everything, years hence, whatever anyone says now. The demands will just never stop until everything is reflected.<o:p class=""></o:p></div></div></div></blockquote><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Not all demands must be satisfied. Other languages (I'm looking at Java) have reflection without expression reflection, for example, so far as I know.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;" class="" type="cite"><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> Start writing your algorithms now, switch your helper functions to whatever standards they decide later.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Regarding parallel naming I think we’re talking about different things — what we’re doing now IS a parallel naming structure. meta::is_constexpr(reflinfo) is a parallel of FunctionDecl::isConstexpr() etc. A full parallel structure of every property is what we’re looking at building. If everyone’s looked hard at that eventuality and are okay with maintaining that, then I suppose I have no cause to complain — maybe it’s not as hard as I imagine.<o:p class=""></o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><br class=""><br class=""><o:p class=""></o:p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class="" type="cite"><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">On Nov 12, 2019, at 8:01 AM, Andrew Sutton <<a href="mailto:asutton.list@gmail.com" target="_blank" style="color: purple; text-decoration: underline;" class="">asutton.list@gmail.com</a>> wrote:<o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;" class="" type="cite"><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I argue the standards should be based on the clang AST. Clean it up first of course — and yes that alone would be extraordinarily difficult. But it’s also very difficult to build a gigantic parallel naming system for reflection properties. And then to maintain it long term…<o:p class=""></o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Best to look hard at what lies ahead, and bite the bullet now. Clean up the AST, define the standard via it. (And c’mon we all know those AST nodes have a lot of flab to go with all their muscle; clang would benefit too after we all finish grumbling about the changes.) Other compilers can do a parallel naming system or adjust their own ASTs to match clang’s naming system — doesn’t need to add any work for them.<o:p class=""></o:p></div></div></div></div></blockquote><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">This is a non-starter for standardization. There are significant and generally incompatible differences in the internal representations of C++ among the different vendors and no will to standardize or even informally adopt a common representation. Even if there were interest in doing so, the engineering cost would be prohibitive, as it would essentially require gutting and rewriting huge swaths of the compiler (and in GCC's case, possibly the middle-end). Parallel naming is also unlikely because of memory requirements.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">You have the same problem with compiled module interfaces, which serialize the internal representation.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Andrew</div></div></div></div></div></blockquote></div></div></div></blockquote></div></div></div></div></div></blockquote></div><br class=""></div></body></html>