DIP28, on properties, availabel for destruction as well

[deadalnix]

On Wednesday, 13 March 2013 at 20:21:27 UTC, Timon Gehr wrote:
> On 03/13/2013 04:55 PM, deadalnix wrote:
>> ...
>>>
>>> No, both DIPs specify it exactly. DIP28 is broken in that 
>>> regard.
>>> But DIP28 leaves it up to imagination what it means for an 
>>> expression
>>> to occur in the left-hand side of an assignment.
>>
>> DIP28 is fixed in that regard. You were right.
>
> (x?setter1:setter2)=y; // ?
>
> (x, setter)=y; // ?
>

With DIP28, it do not work. I do agree this is problem for , 
operator, not sure for ?: .

http://dlang.org/expression.html#ConditionalExpression say 
nothing about rvaluesness or lvalueness of both , and ?: 
expressions in general. It should probably be defined in the 
general case and this should drive property definition.

I feel like DIP28 is broken with comma expression and that DIP24 
is right on that.

I honestly don't really know about ?: expressions.

> struct S{
>     ref int foo(){ ... }
>     int foo(int x){ ... }
> }
> S x;
> x.foo+=2; // ?
>

This is clearly ambiguous. I feel like the getter solution should 
take precedence if that make sense or simply disallow setter when 
getter return an lvalue (as it create all kind of situation when 
you don't know what is called).

> getter.x=y; // ? (x is a field of typeof(getter))

If getter return an rvalue, then it fail. If getter return an 
lvalue, it does work.