Fixing D's Properties

[Bill Baxter]

Chad J wrote:
> Alright I forgot to mention what something like "a.prop.x = foo;" would 
> expand to.
> 
> It would work like this:
> 
> a.prop.x = foo;
> 
> expands to
> 
> auto temp = a.prop;
> temp.x = foo;
> a.prop = temp;
> 
> Whether temp is a reference or value type need not matter, it should 
> work exactly as it would if there was a variable there instead of a 
> property.
> I suppose Sean's suggestion of allowing programmers to trap reference 
> and value uses of properties would work, but I am skeptical that it 
> might break the close compatibility between plain variables (fields) and 
> properties.  It should be feasible as long as there is a way to make a 
> property equivalent to a field wrt calling syntax/semantics.
> 
> Longer chains should be broken down as such:
> 
> a.prop1.prop2.field.prop3.x = foo;
> 
> ->
> 
> auto temp1 = a.prop1;
> auto temp2 = temp1.prop2;
> auto temp3 = temp2.field.prop3;
> temp3.x = foo;
> temp2.field.prop3 = temp3;
> temp1.prop2 = temp2;
> a.prop1 = temp1;
> 
> Hope that helps.

That makes some sense.  Although just avoiding the copying by allowing 
either references or a way to create a light proxy that overloads opDot 
would be more useful.  Then you could return a proxy from 'a' that 
contains just a pointer to prop2.

Either way, D sorely needs a way to overload opDot (akin to C++'s 
operator->).  Not having it eliminates a huge class of useful ways to 
create value wrappers.  There's some seriously cool potential for a CTFE 
template opDot that takes a string giving the member name.

--bb