<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="">Also: if we want to make this a clang-specific feature, all we need to do is define a different version of reflexpr that doesn’t conflict with Andrew’s — e.g. __creflexpr. <div class=""><br class=""></div><div class="">Then anyone can either use either</div><div class=""><br class=""></div><div class="">meta::is_constexpr(reflexpr(myfunc))</div><div class=""><br class=""></div><div class="">OR </div><div class=""><br class=""></div><div class="">__creflexpr(myfunc)->isConstexpr()</div><div class="">__creflexpr(myfunc)->getBody()->… //non-ISO reflections supported here</div><div class=""><br class=""></div><div class="">I will see about implementing that change so everything can live in harmony.</div><div class=""><br class=""></div><div class="">Dave <br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 12, 2019, at 9:04 AM, David Rector <<a href="mailto:davrec@gmail.com" class="">davrec@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Fair enough. </div><div class=""><br class=""></div><div 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.</div><div class=""><br class=""></div><div class="">*Eventually* the standard will support reflecting everything, years hence, whatever anyone says now. The demands will just never stop until everything is reflected. Start writing your algorithms now, switch your helper functions to whatever standards they decide later.</div><div class=""><br class=""></div>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.<div class=""><br class=""></div><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 12, 2019, at 8:01 AM, Andrew Sutton <<a href="mailto:asutton.list@gmail.com" class="">asutton.list@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></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 style="overflow-wrap: break-word;" 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…<div class=""><br class=""><div 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.</div></div></div></blockquote><div class=""><br class=""></div><div 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.</div><div class=""><br class=""></div><div class="">You have the same problem with compiled module interfaces, which serialize the internal representation.</div><div class=""><br class=""></div><div class="">Andrew</div></div></div>
</div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></body></html>