> On Oct 20, 2016, at 8:41 AM, Erik Eckstein <eeckst...@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. 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.
-Andy
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
