Selective control of implicit copying behavior: `take`, `borrow`, and `copy` operators, `@noImplicitCopy`

[Jumhyn (Frederick Kellison-Linn)]

This looks great to me overall! Very nice to have a more complete picture of the ownership story related to take.

@Joe_Groff

func test() {
  var x: [Int] = getArray()
  
  // x is appended to. After this point, we know that x is unique.
  // We want to preserve that property.
  x.append(5)
  
  // We create a new variable y so we can write an algorithm
  // where we may change the value of y (causing a COW copy
  // of the buffer shared with x).
  var y = x
  longAlgorithmUsing(&y)
  // We no longer use y after this point, so we tell the
  // last use to take ownership.
  consumeFinalY(take y)

  // x will be unique again here.
  x.append(7)
}

This as the headline motivating example of take remains unsatisfying to me. The text says take is introduced to solve the problems that 1) there is no "strong guarantee" that the compiler will optimize the lifetime of y to end before the final use of x and 2) future modifications of the code may introduce uses of y that inadvertently extend its lifetime. But as far as (1) goes, it seems even with take we have no such "strong guarantee":

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

As it stands, the move intrinsic does not carry any special side effects. I don't think we want to give it special side effects either. That's contrary to the intent of "just express what we intended the optimizer to do without otherwise inhibiting optimization". So I can't think of a language rule that prevents the transformation above. But I agree that it's harmful optimization behavior and should hopefully never happen in practice. The compiler does have a conservative understanding of where…

@Jumhyn

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?

And (2) still seems problematic since it does nothing for introducing new uses of x that are interleaved with the 'critical section' where y is alive, e.g.:

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

  x.append(6) // non-unique!

  consumeFinalY(take y)

  x.append(7)
}

When I raised this previously it was pointed out that the solution I was reaching for seemed similar to the borrow variables discussed in the updated ownership roadmap, but that still leaves me with questions in regards to take. Is some form of borrow variables the intended solution here? If so, why is this example being used to motivate take?

@Joe_Groff

Note that, unlike true move-only types, all of these would be local, non-transitive restrictions. A no-implicit-copy variable can still be passed to another function that may copy it:

[...]

And concrete types marked as no-implicit-copy would be implicitly copyable when used as generic or existential types (unless those generic values are also marked no-implicit-copy):

Ought we have some sort of marker in these cases at the point where the non-transitivity of @noImplicitCopy causes us to lose its guarantees? It seems a bit silly to provide the functionality of @noImplicitCopy and also allow it to end up getting silently discarded.

And somewhat relatedly, is copy intended to guarantee that the compiler really will emit a copy operation, or does it just serve to allow the compiler to emit a copy when necessary? If the latter, would it make sense to just use copy as that marker to indicate that you may end up copying the value by passing it somewhere that loses its @noImplicitCopy-ness?