[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