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

Okay, this helps crystallize things a bit more for me.

This also makes sense, though I wonder if it is in conflict with the proposal text. The proposal raises the point several times that move serves not only as a tool useful against modifications of the source, but also against optimizer behavior and future language implementation changes. If we don't have the formal language to guarantee that move protects against the language implementation in this way, perhaps it would be appropriate to specify move for now as a source-level guard, and then further specify the semantics once we flesh out the initialization semantics?


Even as just a source-level guard, though, I think the potential for this 'harmful' optimization speaks to a broader discomfort that I've been feeling but haven't been able to put into words until just now. Again returning to the motivating example for move:

func test() {
  var x: [Int] = getArray()
  x.append(5)
  
  var y = x
  longAlgorithmUsing(&y)
  consumeFinalY(move y)

  x.append(7)
}

the proposal sells move as a solution to the problem of "what if someone tries to use y after x.append(7) and accidentally causes an implicit copy"? But that problem is indexed on two bindings, x and y, and the solution is unilateral: it only affects usage of the y binding. Nothing stops an accidental insertion of an x.append(6) within the 'critical' section between the y = x alias and the final move of y, just like the potential 'optimization' discussed before:

var y = x
longAlgorithmUsing(&y)
x.append(6) // oopsie
consumeFinalY(move y)

It seems like the robust solution to the problem posed starts looking more like a Rust-y lifetime system:

var y = strawmanDontUseTheseAtTheSameTimeKeyword x
longAlgorithmUsing(&y)
x.append(6) // error: 'x' cannot be modified while 'y' is still alive (used below)
consumeFinalY(y) // OR error: 'y' used after lifetime implicitly ended (by use of 'x' above)

x.append(7) // OK, lifetime of 'y' implicitly ended here

I haven't really thought this through, but it does seem like it would be better if we could properly express the relationship we're worried about rather than relying on ending the lifetime of a single binding.

2 Likes