Properties: a.b.c = 3

[Steven Schveighoffer]

On Wed, 29 Jul 2009 15:01:47 -0400, Chad J  
<chadjoan at __spam.is.bad__gmail.com> 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?!

Hold on a second, don't we already have semantics that work?  I mean we  
can already write

auto tmp = a.b;
tmp.c = 5;
a.b = tmp;

So what is the big deal?  If your widget.position is a struct with fields,  
then the compiler should be able to detect the error (not yet?) and tell  
you "no, it's an rvalue."

Why should the compiler make assumptions about the logic of code when they  
may be incorrect, and might be better optimized by a person?

I would think that macros would be a better fit for this.

> 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.

It's not the assignments, its the idea that the compiler should workaround  
the poor design of the code by writing possibly incorrect code.  I'd  
rather be in charge of the design of my code, thanks.  If the compiler  
help prevent me from making obvious *provable* mistakes, then fine.  If it  
makes decisions that might be based on incomplete information, I don't  
want that.

-Steve