Properties: a.b.c = 3

[Chad J]

Steven Schveighoffer wrote:
> On Wed, 29 Jul 2009 10:16:33 -0400, grauzone <none at example.net> wrote:
> 
>> Daniel Keep wrote:
>>> Maybe the compiler could rewrite the above as:
>>>  auto t = a.b;
>>> t.c = 3;
>>> a.b = t;
>>>  Unless it can prove it doesn't need to.  Same solution as to the op=
>>> conundrum.
>>
>> Yes! At least that's what the user wants.
>>
>> The compiler has to detect, that the object was modified at all. (To
>> know whether it should generate code to write back the property.)
>> Would this make the compiler much complexer?
>>
>> You also have to deal with nested properties:
>>
>> a.b.c.d = 3;
>>
>> turns to
>>
>> auto t = a.b;
>> auto t2 = t.c;
>> c.d = 3;
>> t.c = t2;
>> a.b = t;
>>
>> ???
> 
> Yeah, I think this idea is no good.  a.b.c.d.e.f = 3, results in one
> gigantic mess, which the user might not want.
> 

!!!

Wait, just what is wrong here?

I mean, so what.  That expression would generate a lot of code if the
compiler were completely naive about this.  It might run slightly
slower.  But, it's probably pretty easy for the compiler to prove that
this doesn't need to happen in common cases (e.g. all members are
fields).  Also, having 5 dotOps in a row like that is very uncommon.  If
you are worried about speed than cache your dereferences.  It's a common
trick.

I still don't see how we can't do this in a very mechanical manner.

> Properties don't have to be exactly like fields.  I think we need to get
> away from that idea.
> 
> It would be nice if the compiler could help by simply rejecting what it
> can reject (assignment to rvalues), but other than that, there's not
> much that can be done.
> 
> This can be detected in simple cases, but in the case where the end
> point is a function, it will be difficult or impossible.
> 
> I don't believe the problem needs to be solved.
> 
> -Steve

There are a lot of problems that don't /need/ to be solved but /should/
be solved.