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:

| 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."

So do I.

[...]

| 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.  :-)

Absolutely.  If that weren't obvious, I would like to restate firmly
that the compile-time reflection thingy is not about high school project.
No.  It is about providing better support for generic programming,
with the primary goal toward easing library design and implementation.

[...]

| > 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?)

You're right.  Actualy, the above sjhoudl read "postfix-expression",
not "primary-expression". 

[...]

| 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.

Maybe that is because there are some confusion about what a built-in
should be.  I don't know on which side that confusion is, but
certainly I do know the difference between a regular C/C++ function
that takes only expressions and an operator-like function that can
take a type-id.

If you take the sizeof route then I would expect you would use
syntactic category "unary-expression".  But then, that category
imposes a very restrictive contraint on the number of the arguments
the operator-like built-in should take. I can't see any compelling
reason to do so.  Certainly  

     offsetof (POD, name)

is not unary.  Even though offsetof is defined to be a macro, nothing
prevents it to expand to 

    __builtin_offsetof (POD, name)

What I'm proposing is to generalize the syntax

        postfix-expression ( expression-list_opt )

to allow "type-id"s in the expression-list.

-- Gaby