DIP28, on properties, availabel for destruction as well

[Artur Skawina]

On 03/14/13 18:20, Timon Gehr wrote:
> 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?

It was a generic comment. I don't think discussing details about these DIPs makes
sense, as, as somebody else already pointed out, they don't mean much, w/o actual
implementations. The proposals may have problems, but as they aren't likely to
impact D in any way whatsoever, I consider the existence of these DIPs to be mostly
harmless. There are far more serious dangers to D. 

Hmm. Anyway, are you proposing that property setters could optionally return 'void'
and would then evaluate to the first (only) arg?  That might actually work; but I
haven't seen it mentioned anywhere. If that was what you were referring to, then I
must have missed it.

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

I wish i could really /use/ D. But it's hard to use it when you encounter serious
problems every ~2 pages of non-trivial code. Either a) compiler limitations, b)
compiler bugs, or c) language problems. The language improves, even if very slowly,
and it would be better if it didn't regress before it gets better, which
unfortunately seems to be a possibility recently... D is the best thing that could
have happened to C, and we can only hope that Walter is able to resist. 


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

And /that/ common case could be avoided. But I'm not even sure that it /is/ the
common case, as i suspect most property accessors are being inlined. So it's
mostly about the non-inline-non-pod-returning extremely complex property
implementations. Which I don't think is a case worth optimizing the language for.

artur