RFC: Return by move

[catamorphism]

In changing code to prepare for #2633, I'm noticing that most of the "copying a noncopyable" errors when I disable last-use have to do with a return, usually a return of a local variable. I propose that a return x should, by default, mean return (move x) when x is an owned lvalue. This avoids the need to insert lots of explicit moves once last-use is disabled.

An argument against this proposal is that the point of #2633 is to make more things explicit, and this proposal makes more things implicit again. However, I think it's easier to understand that "return is move" when you're returning something you own than it is to understand how last-use works.

[bblum]

To write return by copyin cases where this "might" be confusing, you already have to write out the copy, right? fn foo<T:copy>(x:&T) -> T { return copy *x }?

i can't think of any other conflicts; this sounds fine to me.

[brson]

So to return a value we could either write:

fn foo() -> bar {
   move baz
}

or

fn foo() -> bar {
  return baz;
}

This seems ok to me.

[catamorphism]

@brson Yes, either would be correct.

[nikomatsakis]

I was considering a similar rule but that was syntactically determined. Something like:

• If the tail expression of a block is a local variable that is declared inside that block, it is automatically moved
• If the return expression is a local variable or argument, it is automatically moved

I feel strongly that the rule should be the same for blocks and returns.

The idea of generalizing to an arbitrary owned expression is also plausible, though it means that we won't know if something is a move or not until borrowck. That's probably ok.

[nikomatsakis]

Under my proposal, then,

fn foo() -> baz { EXPR }

would always be entirely equivalent to

fn foo() -> baz { return EXPR; }

and also to:

fn foo() -> baz { { EXPR } }

and so forth.

I think it is important to main this invariant.

One problem I can see, though, is that return { x } would not be equivalent to return x. I guess we can generalize the rule to accommodate this case as well.

[catamorphism]

@nikomatsakis Yes, I agree that tail exprs and explicit returns should be handled the same way. I just forgot to mention that.

[graydon]

I'm mostly in agreement (tentatively, not really knowing the complications) with Niko in terms of treating the tail position, in general, as moved-out rather than copied-out. It's not "running a liveness algorithm" to figure out which expression is the tail expression of a block or function: it's a straight syntactic feature, known the moment we parse. Honestly, if you can't figure that out by inspection, you have bigger problems in your code!

(Though I don't understand why return {x} would be different than return x in this proposal)

[graydon]

Oh. I guess there might be some complication here in the region-inference bit Niko and I were discussing, to lengthen rvalue lifetimes from inside blocks. Though I struggle to come up with an example (especially one borrowck wouldn't catch). Am I barking up a meaningful tree here?

[pcwalton]

I guess this is OK.

[nikomatsakis]

@graydon that's not quite what I meant. I just meant that if we are not careful with how we define the rules, then return {x} will not work. For example, my initial thought for how to define the rule was "if the return (resp. tail expression) is a path and the path is a local variable defined in the function block (resp. block), then the value is implicitly moved". But that will not work for return {x} because the return expression is a block, not a path, and the tail expression of {x} is a local variable but not one defined within the block itself.

So the rule has to be more subtle and consider the "destination" of the copy. Something like: "a reference to a local variable is an implicit move if the destination will be out of the variable's scope", but of course we need to define "destination". Essentially it seems like a top-down sort of analysis to me, where each block has a notion of its "destination", with the fn body and any block that appears after a return having a destination of "outside the fn" (in terms of the implementation, perhaps the node id 0). Internal blocks have a destination of the expression that they are a part of. When looking at a block whose tail expression is a local variable, we consider the block's destination id and compare it against the id of the block where the variable was declared. This can be generalized in a fairly straightforward way to arbitrary "owned" expressions, if that seems worth the trouble.

[catamorphism]

In the meeting today, we agreed not to implement this after all, for simplicity. It's not that bad to have to write explicit moves .We can revisit this if it gets too annoying.