Re: [c++, cxx-reflection] Initial thoughts on type reflection.

[Phil Edwards <phil at jaj dot com>]

On Mon, Mar 10, 2003 at 11:51:55PM -0800, Mark Mitchell wrote:
> 
> What are these new magic_foo things, in terms of the existing grammar?

This is something Gaby and I have only discussed very briefly.  My own
approach is based entirely around the precept, "change the grammar as
little as possible."  The result is very simple, very extensible, very
easy to maintain, but leads to some clunky (IMHO) syntax in use.

My feeling is that the underlying builtins/operators/keywords/whatsis will
primarily be used in library code; at least, that's my whole reason for
doing this.  Users of the library will have simple templates to work with.
Users of the builtins are already used to odd syntax.  :-)

Anyhow, if we relax the "as little as possible" restriction, other approaches
open up.


Should point out here, if it's not obvious, that Gaby and I have come up
with multiple approaches.  We each have our favorites.  I'm bringing this
up in the hopes that others might also have suggestions; somewhere in this
search space we'll find a solution we all like.


> 1. primary-expressions
> 
>     That means that you then need to worry about things like   
>     "&magic_foo", and "magic_foo((int))".

I don't think that's what Gaby had in mind.  (Gaby?)


> 2. Operators, ala sizeof.

This is what I've done.

> Using these operators inside templates will work correctly, if you
> introduce something analagous to SIZEOF_EXPR.

Ditto.

> You can reuse things like
> cp_parser_sizeof_operand to handle the parsing and semantic processing.)

Also ditto.  :-)


> There is no reason this has to get messy; you just create a table of the
> operators, and voila, you're done.
> 
> Thinking about these things as builtin functions is not right;
> functions, in C++, do not take types as arguments.  These things are
> operators on types.

My working keyword is __reflect (with REFLECT_EXPR and similar names in the
supporting functions).  We want more than just "traits", in the type_traits
library sense; we want to be able to perform general compile-time reflection
on types, whatever we decide that will be.

I shied away from anything starting with __builtin because having some
__builtin_*'s be operators (like ...va_start) and others be functions
really bothers me.  Personal preference only.


Must explain this in more detail, but I'm late for a meeting I must not miss.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams