[swift-dev] copy-on-write proposal

[Erik Eckstein]

> On Oct 20, 2016, at 10:11 AM, Andrew Trick <atrick at apple.com> wrote:
> 
> 
>> On Oct 20, 2016, at 8:41 AM, Erik Eckstein <eeckstein at apple.com <mailto:eeckstein at apple.com>> wrote:
>> 
>>> To clarify: I proposed an alternate approach in which the @sil_cow reference is only mutable during the Array’s @inout scope—to be automatically enforced by the compiler once @inout scopes are enforced. But the text in question is not referring to that approach, so your comments are on target.
>> 
>> After thinking about Joe’s suggestion (having the cow attribute on the class type and make a reference to that type move-only), I’m more inclined to go with the isUnique builtin. If such a reference can only be returned by isUnique, it is really guaranteed that only a uniquely referenced buffer can be mutated. With the inout approach, the programmer is not forced to make the uniqueness check before modifying the buffer.
> 
> 
> In my mind, relying on a move-only reference type is exactly what I was advocating for, but relies on a language feature rather than a “special” compiler verification.

Well, I think we are not blocked on this. We could just add a mandatory pass to check that there are no move-only violations. In the future a language feature might do this in a more elegant way in the type checker or whatever. But for now I believe we don’t need more than the attributes on the class type and the COW reference field.

> This all still needs to work with an ‘inout’ Array. The compiler will effectively be doing the same verification that I was proposing but as a side effect of move-only semantics (type system support makes it much easier). The isUnique builtin would just be a mechanism to get the mutable type, and the endUnique builtin is the mechanism to move the type back. As Dave pointed out, we could provide additional mechanisms for mutation that don’t depend on uniqueness. But the SIL optimizer doesn’t need to be explicitly taught about any of those builtin mechanisms for correctness. More importantly, the user is no longer responsible for some easy-to-violate, unverified property of the data type as a whole.

I think we are more or less on the same page. All I’m saying is that the mutable reference can only be obtained by the isUnique/is_unique builtin/instruction (or by creating a new buffer).

> 
> -Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161020/30d54a59/attachment.html>