Properties: a.b.c = 3

[Steven Schveighoffer]

On Wed, 29 Jul 2009 18:27:09 -0400, Chad J  
<chadjoan at __spam.is.bad__gmail.com> wrote:

> Steven Schveighoffer wrote:
>> On Wed, 29 Jul 2009 15:01:47 -0400, Chad J
>> <chadjoan at __spam.is.bad__gmail.com> wrote:
>>>
>>> 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
>
> Ah, well that argument has some weight.
>
> I'd like to know though, what assumptions does this make about the code?
>  Why might they be incorrect?

Simply that the compiler assumes it's simply setting a value.  However,  
setters are functions and can execute any code they wish.  You may get  
into weird states that you don't want to or perform unneeded actions that  
you aren't expecting.

The example given later in this thread is perfect -- setting the width and  
height individually may re-render the widget when you only should  
re-render once.

Another example is something like this:

class C
{
   int x;
}
struct S
{
   C c;
}

struct S2
{
   C c;
   S s() { return S(c); }
   void s(S s) {c = s.c;}
}

void main()
{
   S2 s2;
   s2.c = new C;
   s2.s.c.x = 5;
}

If the compiler rewrites that last line as:

auto tmp = s2.s;
s2.c.x = 5;
s2.s = tmp;

Then it is completely unnecessary, and could cause problems if the setter  
does something else besides setting.

> If the compiler /knows/ that something being used is a property, I just
> don't understand how that information is incomplete.

First, because the problem of determining what code does is an NP-complete  
problem -- the compiler can't know what code is going to do except by  
running it.  It's just like trying to write a program that detects  
infinite loops.  So it must make some assumptions.

Second, because D allows opaque function declarations, so the compiler  
might not even be able to *look* at what a property does.  It can only  
assume, and the assumption you would have it make is that a property is a  
simple setter that has no other side effects.

> Also macros aren't a good fit for this because they aren't going to
> exist in D2, or necessarily ever.  Well, properties may not pop up in D2
> either, but if they're going to happen it'd be nicer if they did.

I think you can solve this problem (and solve it correctly) with some sort  
of fancy template magic, but not without some extra baggage (such as an  
extra type that might not be optimized).  I envision something like this:

with(Setter!(widget.location)) // don't know if this works
{
    width = 50;
    height = 100;
    // at scope end, Setter sets widget.location to it's internal  
representation via a finalizer
}

The reason I said macros is because they have the power to rewrite the  
code exactly like you said the compiler should.  At least with a macro you  
would have some indication that it is exactly what the user wants, and you  
can have the power to do your optimizations.

-Steve