A new take on Move, Copy, and assignment

[dabrahams]

@kyouko-taiga and I chatted today about Movable and Copyable and decided there was room for more symmetry. I'm writing this up to capture that idea and nail down a few things we didn't discuss explicitly to make sure there's agreement.

First, the traits as they should be defined:

/// A type whose values can be relocated to different storage.
public trait Movable {

  /// Gives `self` the value of a consumed `source`.
  fun take_value(from source: sink Self) inout {
    set
    inout
  }

}

extension Movable {

  /// Consumes and returns `self`.
  public fun move() sink -> Self {
    let r: Self
    r.take_value(from: self)
    return r
  }

}

/// A type whose values can be copied to different storage.
public trait Copyable: Movable {

  /// Gives `self` the value of a consumed `source`.
  fun copy_value(from source: Self) inout {
    set
    inout
  }

}

extension Copyable {

  /// Returns a copy of `self`.
  public fun copy() -> Self {
    let r: Self
    r.copy_value(from: self)
    return r
  }

}

Initialization and assignment are tied to these traits, so

var lhs = rhs

Will use the set variant of Movable.move_value(from: rhs) or of Copyable.copy_value(from: rhs) in case rhs is used again.

&lhs = rhs

Will use the inout variant of Movable.move_value(from: rhs) or of Copyable.copy_value(from: rhs) in case rhs is used again.

Additional .move() or .copy() operations on rhs can be elided by the compiler in each of these cases.

[kyouko-taiga]

One use case we had in mind for a type that is movable but might require a custom take_value(from:).set is to handle a type whose value depends on its location in memory, like a list that would use its head pointer as a sentinel.

[kyouko-taiga]

You mean under @implicitcopy? Otherwise no copy would ever occur.
Still, there's quite a bit of magic going on with these statements so let's recap.

var lhs = rhs is a bit special. The compiler will try hard to avoid building a rhs before initializing the lhs and so most of the time the statement will desugar to an initializer call. This transformation is important because we must deal with non-movable types.

var lhs = T() // note: `T` may not be `Movable`

// ↑ becomes ↓

var lhs: T
T.init(&lhs)

Note: non-movable types include any type with remote parts (e.g., a capturing lambda).

If the rhs is not a constructor call, then we'll use the conformance from movable and rewrite the initialization as a call to take_value(from:).set:

var lhs = rhs

// ↑ becomes ↓

var lhs: T
(T::Movable).take_value.set(self: &lhs, from: rhs)

&lhs = rhs will always use a conformance to Movable, implying that one cannot separate the declaration and the initialization of a non-movable type. The statement will be rewritten as a call to Movable.take_value and definite assignment analysis will figure out which variant is picked.

&lhs = rhs

// ↑ becomes ↓

(T::Movable).take_value(self: &lhs, from: rhs)

Now if we had @implicitcopy I we would first rewrite var lhs = rhs as var lhs = rhs.copy(). Likewise we would rewrite &lhs = rhs as &lhs = rhs.copy(). From there, we would identify ... = truc.copy() as a special pattern and use a conformance to Copyable the way you described:

@implicitcopy
var lhs = rhs

// ↑ becomes ↓

var lhs = rhs.copy()

// ↑ becomes ↓

var lhs: T
(T::Copyable).copy_value.set(self: &lhs, from: rhs)

and

@implicitcopy
&lhs = rhs

// ↑ becomes ↓

&lhs = rhs.copy()

// ↑ becomes ↓

var lhs: T
(T::Copyable).copy_value(self: &lhs, from: rhs)

Additional .move() or .copy() operations on rhs can be elided by the compiler in each of these cases.

Yes

Another transformation to consider is the return from a function. Assume we have fun f() -> T { rhs }, similar rules apply. If rhs is a constructor call, then we will call the corresponding initializer on the location of the return value (recall that the Hylo's calling convention requires that the caller provide space for the return value). Otherwise, it will use a conformance to Movable.

[dabrahams]

Thanks for all this. I agree. In the more general case where return is required, I don't think we should use a conformance to Movable unconditionally if the returned thing is a constructor call. If it is a local variable or let, the compiler can arrange for that to use the storage passed for the return value.

I guess the assignment syntax with a trailing .copy() is special in the way I described for Copyable. Otherwise there would be no way to reuse existing storage.