[cfe-dev] Reflection/metaparsing implem

[David Blaikie via cfe-dev]

On Tue, Nov 12, 2019 at 6:04 AM David Rector <davrec at gmail.com> wrote:

> Fair enough.
>
> 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.
>
> *Eventually* the standard will support reflecting everything, years hence,
> whatever anyone says now.  The demands will just never stop until
> everything is reflected.
>

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.


>  Start writing your algorithms now, switch your helper functions to
> whatever standards they decide later.
>
> 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.
>
>
>
> On Nov 12, 2019, at 8:01 AM, Andrew Sutton <asutton.list at gmail.com> wrote:
>
>
> 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…
>>
>> 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.
>>
>
> 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.
>
> You have the same problem with compiled module interfaces, which serialize
> the internal representation.
>
> Andrew
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191112/049b7334/attachment.html>