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

["Doug Gregor" <doug dot gregor at gmail dot com>]

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.

 Cheers,
 Doug