DIP28, on properties, availabel for destruction as well

[Timon Gehr]

On 03/13/2013 04:55 PM, deadalnix wrote:
> On Saturday, 2 March 2013 at 16:48:14 UTC, Timon Gehr wrote:
>>>  - typeof(__traits(propertyAccessors, prop)(exp)) is void and its
>>> result is used. I don't see the point of special casing this.
>>
>> Consistent support for multiple assignment.
>>
>
> It isn't prevented by DIP28. Plus, this is already the behavior of
> opAssign and firends.
>

Well, I do not feel particularly strongly about it. It is moved to 
possible extensions now. It should then probably also apply to opAssign 
and friends.

>>> It increase complexity
>>
>> Yup, marginally.
>>
>>> and reduces what you can express.
>>>
>>
>> Not strictly.
>>
>
> It does.

In some ways, and in other ways expressiveness is extended, therefore it 
does not _strictly_ reduce expressiveness.

I do not think that the kind of expressiveness removed is useful. Why 
would it be?

> I''m not sure that the extra possibility are really useful, but
> I'm reluctant to increase complexity to reduce expression capabilities
> (unless they cause real problems).
>

Currently there might be unnecessary overhead for returning a result if 
it is not used. Since a property will usually hold on to the value, this 
can be a problem if a struct is expensive to copy. Hence the implementer 
may choose to not support multiple assignment for performance reasons 
(justified or, usually, unjustified). Hence generic code cannot rely on 
multiple assignment working, which is not nice.

>>> It is unclear what happen when the property is aliased or passed as
>>> alias parameter in both DIP, and should be effectively corrected.
>>
>> 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.

Ok, will check.