DIP28, on properties, availabel for destruction as well

[Artur Skawina]

On 03/13/13 21:16, Timon Gehr wrote:
> 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.

Compiler optimization territory. The compiler can clone the function, create a copy that
doesn't return a result; callers that don't need one (and don't inline the callee) can
then use that clone. The case where a function always returns the argument (like property
setters will typically do) can also be handled more efficiently (yes; this can get a bit
more interesting, specially for non-pod types).

artur