DIP28, on properties, availabel for destruction as well

[deadalnix]

On Thursday, 14 March 2013 at 11:04:44 UTC, Artur Skawina wrote:
> 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

It can't when it come to copy contructor/destructor of structs if 
they aren't pure and trivials.