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

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Phil Edwards <phil at jaj dot com> writes:

| > want them to me marked BUILT_IN_FRONT_END.  Our built-ins will be
| > expanded by the front-end (into a tree or GIMPLE or whatever it gets
| > called by the time we merge).
| 
| Actually...  I think this is somewhat moot, since none of the builtin
| functions can take types as arguments.  Which leaves two options:
| 
| 1)  Add __builtin_* expressions to the parsers.  One already exists, in
|     the form of __builtin_va_arg.  That isn't handled by the BUILT_IN_*
|     tags at all:
| 
|     /* Expand __builtin_va_arg, which is not really a builtin function, but
|        a very special sort of operator.  */
| 
|     So, going that route sort of obviates any BUILT_IN_* stuff as far as
|     I can tell; the "operators" are handled specially.

Whether you call it "operator" or built-in that takes a type-id does
not change anything fundamental at all.  

I don't want to add a myriad of __builtin_xxx in the grammar. 
If it token with __builtin_ we know it falls in the compiler built-ins
set, then we lookup a table to see whether it takes only expressions
or it expects type-id.  
Speaking C++, the code that parses the built-in arguments is
implemented as a virtual function and only knows the argument-list
detail.  The calling routine only knows that it is parsing a
"postfix-expression". 


| 2)  Do something else.  My implementations have all gone this route, and
|     pay a small price in readability.
| 
| 
| > The invariant here is that, the ressult
| > of the expansion is still something that conceptually happens at the code
| > source level.
| 
| Absolutely.  If you can convince people that changing expand_builtin to not
| return rtx is a good idea, that'd be great.

Well, my goal isn't to conince people that they should not return rtx;
in fact, I want them to conceive  room for something that is not rtx :-)

-- Gaby