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

[Jason Merrill <jason at redhat dot com>]

Russell Yanofsky wrote:
> On Sat, 2007-03-10 at 23:23 -0500, Doug Gregor wrote:
> > Jason is saying that it would be better if we could
> > keep *all* of the changes in the C++ front end, and not touch any of
> > the common bits (tree.c, tree.h).

Yep.

> Why would you actually want to do this? References are a C++ only
> notion, aren't they? By the same logic you would try take references out
> of the middle end and implement them as pointers or something.

As mentioned elsewhere in the thread, refs are not unique to C++.  And 
even if they were, existing design problems are not a justification for 
adding more.

> I know
> the build_rval stuff is ugly, and I'd like to fix that. But is wrong
> with sticking with a simple boolean field in REFERENCE_TYPE nodes? 

The problem is with adding more C++-specific logic to non-C++ files.

> I mean you are talking about bringing TYPE_NEXT_REF_TO into the front
> end. TYPE_NEXT_REF_TO is an internal detail of REFERENCE_TYPE nodes
> currently handled by the middle end, and you want to bring it into the
> front end, as well as add some kind of ordering assumption to the
> TYPE_NEXT_REF_TO list. Any way you do this you are going to have some
> kind of interaction between the front and middle ends. It would make
> sense to me to want to keep that interaction as simple as possible, and
> you can't get much simpler than a boolean field.

TYPE_NEXT_REF_TO is part of the interface of the middle end, since it's 
defined in tree.h, but I agree that mucking in the middle end's data 
structures is inelegant.  But there are other ways you could look up the 
rvalue ref type from the lvalue ref type that wouldn't have that problem.

I think the boolean field is necessary, too, for distinguishing between 
lvalue and rvalue types.  But it can be internal to the front end, 
perhaps using TYPE_LANG_FLAG_2.

BTW, I agree that rvalue refs should use the same tree code as lvalue 
refs.  They are much more alike than pointers and pointers to members.

Jason