DIP28, on properties, availabel for destruction as well

Timon Gehr timon.gehr at gmx.ch
Sat Mar 2 08:48:13 PST 2013


On 03/02/2013 05:22 PM, deadalnix wrote:
> On Saturday, 2 March 2013 at 16:00:55 UTC, Timon Gehr wrote:
>> On 02/27/2013 04:46 PM, deadalnix wrote:
>>> Here come the sister of DIP27 : DIP28 http://wiki.dlang.org/DIP28 .
>>>
>>> It address specifically properties. A 3rd one is coming on delegate. As
>>> for DIP27, the goal is to go aggressively for simplicity.
>>
>> Ignoring complexities and complications is not called simplicity, it's
>> simplism.
>>
>> DIP27 s a simplistic subset of DIP24.
>
> DIP24 and DIP28 are very similar in regard of property, that is exact.
> (As it is in DIP28 topic, I assume that you meant DIP28).
>
> Main difference I see :
>   - Introduction of __traits(propertyAccessors, propertySymbol) . This
> is loosely correlated to the content of each DIP. Both can do with or
> without.

Agreed.

>   - 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 increase complexity

Yup, marginally.

> and reduces what you can express.
>

Not strictly.

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


More information about the Digitalmars-d mailing list