Properties: a.b.c = 3

[Chad J]

Chad J wrote:
> Steven Schveighoffer wrote:
>> On Wed, 29 Jul 2009 14:22:26 -0400, grauzone <none at example.net> wrote:
>>
>>> 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.
>>> I don't want to type out that mess as a user either...
>> What I meant was, I wouldn't want something like a.b.c.d.e.f = 3 to
>> generate the equivalent of 25 lines of code.
>>
>>> Design changes to avoid that mentioned mess would interfere with the
>>> goal of abstraction (e.g. assume you have widget.position, now how do
>>> you set only the x coordinate? yeah, split the property into
>>> position_x and position_y. Result is you have more noise, and you
>>> can't use a Point struct.)
>> option 1, return a ref Point struct
>> option 2, return a special struct which uses properties to set the
>> values in the original widget.
>>
>> I don't think it's an impossible problem to solve, I just don't think
>> the compiler should be involved, because it makes it too easy to
>> gerenate horrible code.
>>
> 
> So we could have semantics that actually work, but you don't want them
> because, oh man, my code might have to do a few more assignments.  A few
> assignments.  Really?!
> 
> !!!!
> 
> Assignments aren't even that expensive!  They are one of the easiest
> operations your CPU can perform!  It's like you'll have a few more MOV
> operations laying around in the worst case.
> 
> If there are dereferences involved it has to break up the expression
> ANYWAYS.
> 
> ARGH!
> 
> You'll have to forgive me.  What I'm reading here is quite frustrating.
> 

Thinking about it a little more, the extra temporaries could run you out
of registers.  That still sounds like a negligable cost in most code.

As I've mentioned elsewhere, it's also really easy to optimize this by
hand if it ever becomes a performance problem.

>> Now, having the compiler reject invalid assignments is definitely
>> something I can live with.
>>
>> -Steve