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

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

Mark Mitchell <mark at codesourcery dot com> writes:

| > | > 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". 
| 
| Every primary-expression is a postfix-expression;

Yeah, in the same way a primary-expression is a unary-expression or an
additive-expression.

But, in reality, we all know that *there is a difference* between a
primary-exprssion and postfix-expression as can be seen from the
production of both syntactic categories. 

| that is the only use  of primary-expression in the grammar. 

I can't understand what you mean here.

| "magic_foo (3)" might be
| postfix-expression, but "magic_foo" by itself could be a
| primary-expression.  I don't think that makes sense, which was my point;
| you want to avoid "magic_foo" by itself being a complete expression. 

Right.

| Instead, "magic_foo" should only be legal if followed by arguments.

Yes.

| You could do that either via introducing new analogues to typeid, or new
| analogues to sizeof.

What does "analogues to typeid or analgues to sizeof" means here?
That is not a rhetorical question because typeid implies
postfix-expression and you seem to argue against postfix-expression.
 
| > What I'm proposing is to generalize the syntax
| > 
| >         postfix-expression ( expression-list_opt )
| > 
| > to allow "type-id"s in the expression-list.
| 
| This is both complicated and unncessary.

Why and how?  

Please note that the syntactic category "postfix-expression" includes
the followinf productions:

    typeid ( expression )
    typeid ( type-id )
     

which matches what I'm proposing.  

Maybe we are just saying the same thing with different background.  I
would like you elaborate on how what I'm proposing is complicating things.

| These new magic things are keywords, not functions.  They are like
| typeid or sizeof, not like sin or strcmp.
| 
| In the past, you've argued against this for "scalability".  But that's a
| red herring; you can easily have a table of codes corresponding to the
| new operators and make a REFLECTION_EXPR to handle all of these
| expressions.

I do not believe that is a red herring because:

  1) the scalability I'm talking about is the ability to add new
     compile-time facilities (or operator to use your vocabulary)
     without having each time to damage the grammar.

  2) certainly, table-driven approach is what I'm implementing and
     what I think Phil is using.

-- Gaby