[Issue 14638] New: The last (in lexical order) copy of an object must be a move

[via Digitalmars-d-bugs]

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 at puremagic.com
          Reporter: andrei at 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.

--