digitalmars.D.bugs - [Issue 14638] New: The last (in lexical order) copy of an object
- via Digitalmars-d-bugs (65/65) May 31 2015 https://issues.dlang.org/show_bug.cgi?id=14638
https://issues.dlang.org/show_bug.cgi?id=14638 Issue ID: 14638 Summary: The last (in lexical order) copy of an object must be a move Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: nobody puremagic.com Reporter: andrei erdani.com Consider (also http://dpaste.dzfl.pl/87e95af25781): struct S1 { this(this) { assert(0); } } struct S2 { disable this(this); } void fun(S1 s) { gun(s); } void gun(S1 s) { } void hun(S2 s) { iun(s); } void iun(S2 s) { } void main() { fun(S1()); hun(S2()); } This code creates an S1 and an S2 as rvalues and passes them by value into functions. These functions in turn forward the values to other functions, also by value, after which they make no more use of the values. If a conversion to an rvalue is the last (statically determined) operation on a value in the lexical scope of a variable, then that copy should count as a move. That should be guaranteed, not an optimization. This rule would automatically enable a lot of sensible code to work with noncopyable values. This matter is a semi-blocker for std.allocator because most allocators are noncopyable. BTW this does not need to go into guessing the last dynamic use. For example: void hun(S2 s) { iun(s); // last dynamic use if (false) { writeln(s); // last static use } } In this case, the call to iun() may create a copy even though an analysis shows the last static use can never happen. Eliding the last dynamic copy may be implemented as an optimization. Checking for disable should still be inserted regardless of the optimization. --
May 31 2015