[cfe-commits] r67059 - in /cfe/trunk: include/clang/AST/ include/clang/Basic/ lib/AST/ lib/CodeGen/ lib/Sema/ test/Parser/ test/SemaCXX/
Howard Hinnant
hhinnant at apple.com
Mon Mar 23 10:12:25 PDT 2009
On Mar 23, 2009, at 1:01 PM, Howard Hinnant wrote:
> On Mar 23, 2009, at 12:35 PM, Douglas Gregor wrote:
>
>> On Mar 21, 2009, at 8:11 AM, Howard Hinnant wrote:
>>
>>> On Mar 20, 2009, at 4:17 PM, Douglas Gregor wrote:
>>>
>>>> Howard, there's a question for you below. Just search for your
>>>> name.
>>>
>>> I didn't see a question.
>>
>> Errr, sorry. The question was: do you agree that the following code
>> should be ill-
>> formed?
>>
>> struct A { };
>>
>> struct B {
>> operator A&&();
>> }
>>
>> void test(B b) {
>> const A &ar = b; // error: operator A&&() returns an rvalue, so
>> it should not be considered when trying to bind ar to b
>> }
>
> I'm not positive. However assuming that this is ill-formed:
>
> struct A { };
>
> struct B {
> operator A&();
> }
>
> void test(B b) {
> const A &ar = b; // error: operator A&() returns an lvalue, so it
> should not be considered when trying to bind ar to b
> }
>
> (by some rule buried in [over]), then I see no reason to have operator
> A&&() behave differently (it should also be ill-formed). If however
> my assumption is incorrect, then I would like to investigate this
> further.
I think I'm officially confused. It appears to me that the use of both:
operator A&();
and
operator A();
would be well formed. What is the motivation (or reference to rule)
to disallow operator A&&() in this context?
-Howard
More information about the cfe-commits
mailing list