SE-0519: Borrow and Inout types for safe, first-class references

[Alejandro (Alejandro Alonso)]

@KeithBauerANZ

-1 for failure to address the overlap between this proposal and the borrowing accessors proposal. The two features aren't even close to orthogonal, so we should certainly not have both in the language. One of the two should expand to cover the use-cases for the other.

I very briefly mentioned this in the pitch thread here: `Borrow` and `Inout` types for safe, first-class references - #24 by Alejandro

Subscripts are weird and can only return a single type. For things like Array, you could theoretically have a single subscript return both a Borrow<Element> and Inout<Element> but like I mentioned in the linked post, you create an ambiguity problem:

struct Array<Element: ~Copyable>: ~Copyable {
  subscript(i: Int) -> Borrow<Element> {
    get { ... }
  }

  subscript(I: Int) -> Inout<Element> {
    mutating get { ... }
  }
}

let a = Array<Atomic<Int>>(...)
let b = a[0] // error: ambiguous use of subscript what type is 'B'?

While the borrow/mutate accessors don’t make it completely obvious from their return type that what’s being returned isn’t an Element, but rather technically Borrow<Element/Inout<Element>, it does resolve this ambiguity issue that Swift has.

@KeithBauerANZ

-1 for these are the wrong names, and/or the borrow accessors proposal is using the wrong names; the exact same concept shouldn't be Inout in one and mutate in the other.

This is fair, should the mutate accessor be called inout? Is that confusing? Mutate<T>?

@KeithBauerANZ

-1 for these are the wrong names, they should line up with Span/MutableSpan, on which front the ship has already sailed.

I think lining up with the Span names would be hard unless you meant X and MutableX. Ref and MutableRef? SpanOfOne/MutableSpanOfOne?