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.
