Uncoupling Movable from sink

[kyouko-taiga]

We currently require that values passed to sink parameters be of types that conform to Movable. The justification is that, often, a sink parameter serves to take values that will be stored or returned. Constructors are typical example:

type Vector2 {
  public var x: Float64
  public var y: Float64
  public init(_ x: sink Float64, _ y: sink Float64) {
    &self.x = x; &self.y = x
  }
}

As @dabrahams and I have discussed while reviewing the specification, however, we should note that sink doesn't actually require any move. We're only transferring ownership, which is a notional property that is erased at run-time. For example, there would be nothing wrong with this program if the above-mentioned requirement was lifted:

type A: Deinitializable {
  public memberwise init
}
public fun f(_ a: sink A) {}
public fun main() {
  sink let a = A()
  f(a)
}

Another role currently served by Movable is to prevent capturing objects from escaping, as we require a conformance to Movable to return or assign a value. For example, a lambda with a let or inout capture is not Movable and therefore it cannot be returned.

We could distinguish escapability from movability by using two different traits. Escapable would describe types whose instances can be freely returned while Movable would relate strictly to a change of storage. Capturing lambdas (and other types containing remoteparts) would not be escapable. For example, foo would be illegal but bar wouldn't in the following:

public fun foo() -> [remote Int]() -> Int {
  sink let x = 0
  return () => x.copy() // '[remote let Int]() -> Int' does not conform to 'Escapable'
}

public fun bar() -> [Int]() -> Int {
  sink let x = 0
  return [sink let y = x.copy()]() => y.copy()
}

Returning without a conformance to Movable would add a couple of restrictions so that the compiler can guarantee that it knows how to build the returned value "in-place". For instance, ham would (most likely) be illegal but muk wouldn't in the following:

type A: Escapable { ??? }
public fun ham() -> A {
  sink let x = A(1)
  sink let y = A(2)
  return if Bool.random() { x } else { y }
}

public fun muk() -> A {
  return if Bool.random() { A(1) } else { A(2) }
}

[dabrahams]

To fill out the picture, part of the motivation is to close the cognitive gap that occurs when you realize sinking a object doesn't require moving it, but that we are requiring Movable conformance. An Escapable type would only be able to contain other Escapable types.

I think this feature, with a conditional conformance for Array, could make remote parts a lot more usable. That said, we think it's not urgent to have this feature and the decision about whether to implement it should be driven by usage experience.