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.
