Property rewriting; I feel it's important. Is there still time?

[Steven Schveighoffer]

On Wed, 10 Mar 2010 17:16:11 -0500, Pelle Månsson  
<pelle.mansson at gmail.com> wrote:

> On 03/10/2010 10:14 PM, Steven Schveighoffer wrote:
>> I think this is fine as long as we don't take it to the extreme. That
>> is, I don't want to see this happening:
>>
>> foo.prop1.prop2++;
>>
>> is rewritten to
>>
>> auto p1 = foo.prop1;
>> auto p2 = p1.prop2;
>> p2++;
>> p1.prop2 = p2;
>> foo.prop1 = p1;
>>
>> I think one level of lowering is enough to handle the most common cases.
>>
>> Of course, if a property returns an lvalue, then it should just work.
>>
>> -Steve
>
> Why would you not want that? That's exactly what should happen! Why not?  
> I'm sorry if I'm missing something obvious.

Hm... on second thought you are right.  I meant to say something like this:

foo.prop1.prop2.bar();

should not be rewritten in a similar fashion.  ++ or op= in most cases  
should change the value of the property, but arbitrary functions are not  
as obvious.

The other thing I don't like about this is it is difficult for the  
compiler to determine what is considered an rvalue or lvalue.  Consider  
something like this:

struct S
{
   int x;
   int *y;
   ref S opAssignOpBinary(string op)(int other) { mixin("*y " ~ op ~ "  
other"); return this; }
}

I believe the compiler considers S an rvalue, but the operator for += will  
work as if it was an lvalue.  To do that whole property shell-game for  
this will be a complete waste.  It makes things like smart pointers  
perform way worse than they should.

What may be a good-enough rule is that the property rewriting is done only  
if the end property (the one being affected) is a pure value type, or a  
builtin and the compiler can tell that the operation only affects that  
property.

Without full code inspection, the "right" solution can't be had.

-Steve