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

[Russell Yanofsky <russ at yanofsky dot org>]

On Sat, 2007-03-10 at 23:23 -0500, Doug Gregor wrote:
> On 3/10/07, Russell Yanofsky <russ@yanofsky.org> wrote:
> > > I'd rather not expose the concept of an rvalue reference to the back
> > > end, its semantics should be encapsulated by the front end.  I think the
> > > right answer is to have a wrapper for build_reference_type_* in the
> > > front end to handle the extra semantics.
> > >
> > > I'm not sure what the best coding strategy is for this.  One option
> > > would be to establish a convention of putting the rvalue ref after the
> > > non-rvalue ref in the TYPE_NEXT_REF_TO chain, or in some other field if
> > > there are others free, so that the C++ front end function can call the
> > > back end function and then use the result to look up the rvalue version.
> >
> > It seems to me like everything you said is already implemented. Rvalue
> > reference types become part of the TYPE_NEXT_REF_TO chain just like
> > other variants of reference types. And build_reference_type() is the
> > front-end wrapper for the build_reference_type_for_mode() function.
> 
> I think Jason is saying something different. TYPE_REF_IS_RVALUE is a
> flag defined in tree.h, which is used by several front-ends and the
> middle-end, although the rvalue references features itself is a
> C++0x-only notion. 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). He's suggesting a way that one could
> implement a new wrapper around build_reference_type, say,
> cp_build_reference_type (tree type, bool rval) just in the C++ front
> end. cp_build_reference_type could use the convention he mentions
> based on TYPE_NEXT_REF_TO to make the rvalue reference of a type
> easily found by this function in the C++ front end while not
> disturbing the other front ends or the middle end.

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

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.

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

Attachment: signature.asc
Description: This is a digitally signed message part