DIP28, on properties, availabel for destruction as well

[Timon Gehr]

On 03/14/2013 01:26 PM, Artur Skawina wrote:
> 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

What's an important case not considered?

> and "fixing" the rest of the problem by banning useful constructs.

Which useful constructs?

> My point is that designing the language around compiler limitations (which aren't
> always even there) is wrong.

Why do you use D then? If only language expressiveness matters, D is not 
at the top.

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

Didn't get any of this.

It's not too common that the perf hit _exists_, but if it does, the 
common case at the call site is that it is taken.