DIP28, on properties, availabel for destruction as well

Artur Skawina art.08.09 at gmail.com
Thu Mar 14 05:26:29 PDT 2013


On 03/14/13 12:42, deadalnix wrote:
> 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).
> 
> It can't when it come to copy contructor/destructor of structs if they aren't pure and trivials.

That's what I meant by "can get a bit more interesting, specially for non-pod types".
But it can be done, the "interesting" parts may involve other language changes. W/o 
changes, /some/ (non-pod) cases can still be handled; it's just that I'm going for a
complete solution, not just allowing a small subset and "fixing" the rest of the
problem by banning useful constructs.
My point is that designing the language around compiler limitations (which aren't
always even there) is wrong. Especially in situations like this one, where the
problematic case is rare, and will get less problematic eventually when the language
evolves. We're talking only about callers that actually use the results of setters -
optimizing for this case is fine, but defining the language specifically to avoid the
rare case, which will take a small perf hit (well, actually not improve, that cost
already exists), does not seem justified.

artur


More information about the Digitalmars-d mailing list