Re: [PATCH] rvalue reference implementation for C++0x

[Russell Yanofsky <russ at yanofsky dot org>]

I'm sympathetic to the notion that if you ever want to tell the  
difference between kinds of types, you should use different type  
nodes. That seems analogous to the strategy when working with  
databases of making sure every row has a single-column primary key.  
It's a little bit of work up front that can save a little work in the  
future, and in the meantime makes everything symmetric and consistent.

In the case of rvalue references, implementing this would require more  
than just a little work, but I'm willing to do it if the GCC commiters  
(I'm not really sure who is who) reach a consensus and tell me that's  
what they want. The tradeoff in doing this is the my patch will go  
from a small 352 line change (counting + lines) that only touches the  
exact parts of the C++ front end that deal with rvalue references, to  
a much larger change affecting every place references are handled.  If  
you guys are willing to review that, I'm willing to implement it. The  
benefit seems abstract to me, but perhaps it is more concrete to  
people who work with GCC every day. Andrew Pinski said something about  
creating a special type node that exists only within the frontend and  
gets converted into a regular REFERENCE_TYPE node during  
gimplification. I don't  know the details, having only worked with the  
C++ front end up to this point, but I'm guessing that's the way to go?

If there is no consensus on this issue, or if the costs of adding a  
boolean flag to the REFERENCE_TYPE node are overstated, then I think  
the best approach is to keep the flag, but to dress it up as something  
which is language neutral using the renames I suggested before. The  
other frontends do not even need to know the flag exists.


--
-  Russell Yanofsky (PGP ID: 0x5FAA0216)
-  http://russ.yanofsky.org/
--