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

[Mark Mitchell <mark at codesourcery dot com>]

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

Let's drop this; I think this is just a language barrier.
 
> | 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.  

You proposed:

  postfix-expression ::= 
   postfix-expression ( expression-or-type-id-list-opt)

  expression-or-type-id-list:
    expression
    | expression , expression-or-type-id-list
    | type-id
    | type-id , expression-or-type-id-list

If you want these new expressions to be postfix-expressions, that's fine
with me, but I don't like your production.  Instead, you should use:

  postfix-expression ::=
    magic_foo ( type-id , expression )
    | magic_bar ( type-id, type-id )
    | magic_baz ( expression )
    | magic_baz ( type-id )

That is how typeid works; it is a keyword with special operands.
  
> | 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.

There's no "damage" to the grammar above.  You're introducing new
keywords, and that's shown in the grammar.  Every time you add a new
keyword, you change the meaning of some existing programs, but that's OK
because the new keywords start with two underscores.

The thing is that these things are *keywords* -- they are not
identifiers.  For example, it makes no more sense to have a variable
named "magic_foo" than it does one named "typeid".

-- 
Mark Mitchell
CodeSourcery, LLC
mark at codesourcery dot com