SE-0366: Move Function + "Use After Move" Diagnostic

[Chris_Lattner3 (Chris Lattner)]

I think the proposal is nice, and particularly appreciate the attention to detail with defer and repopulating an inout after moving from it.

I agree with the general concerns above. move isn't a function and breaks composition in weird ways, it is built-in.

I think that Xiaodi's suggestion is good, given that operators feel more "built in".

@xwu

I want to throw out perhaps a middle ground here: What about a standard library operator?

I'm not referring to making move an operator spelled as-is, I mean some counterpart to f(&x) for inout which could be declared as a regular standard library operator but, by virtue of eschewing the standard function calling parens at the call site, avoids reading as "just any old function."

For example, suppose we spelled the operation as prefix <-:

// Proposed syntax:
f(move(x))
// New bikeshed syntax:
f(<-x)

// Proposed syntax:
let y = move(x)
// New bikeshed syntax:
let y = <-x

I'd throw out <* or <= or << or <@ as other examples for consideration, e.g.:

  var y = x
  longAlgorithmUsing(&y)
  // We no longer use y after this point, so move it when we pass it off to
  // the last use.
  consumeFinalY(<*y)
...

  _ = <*x

Both connote "pulling the value out of the RHS".

-Chris