This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] rvalue reference implementation for C++0x
- From: Jason Merrill <jason at redhat dot com>
- To: Russell Yanofsky <russ at yanofsky dot org>
- Cc: gcc-patches at gcc dot gnu dot org, Jason Merrill <jason at redhat dot com>
- Date: Fri, 09 Mar 2007 16:26:14 -0500
- Subject: Re: [PATCH] rvalue reference implementation for C++0x
- References: <1172076241.31795.32.camel@turtle>
Mostly looks good. A few comments:
Need a space before the ( in many of the uses of TYPE_REF_IS_RVALUE and
some other places.
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.
Please quote the reference collapsing rules where you implement them in
grokdeclarator and tsubst.
I'd change "valuedness" to "rvalueness" for clarity, as "valuedness"
could mean "the state of having a value".
The test in compare_ics seems to check for cases where one conversion
has matching rvalueness and the other doesn't, but that isn't all the
rule in the working paper talks about: it also requires that for one ICS
to be better than the other, the two references must differ in
rvalueness, one converting to lvalue ref and the other to rvalue ref or
In lvalue_p_1, I'd clarify the INDIRECT_REF comment by noting that the
INDIRECT_REFs are just internal compiler representation, not part of the
language, so we have to look through them.
Please send mail to email@example.com about allocating a new
type encoding for rvalue references. Since this is part of C++0x, it
shouldn't be mangled using a vendor extension, it should be added to the
standard ABI. Also, I'd expect it to be used instead of the "R" for an
lvalue reference, not in addition.
About the deduce_ref stuff: why not just add the REFERENCE_TYPE to arg
in type_unification_real rather than add another argument to unify?