> On Oct 20, 2016, at 10:11 AM, Andrew Trick <atr...@apple.com> wrote: > > >> On Oct 20, 2016, at 8:41 AM, Erik Eckstein <eeckst...@apple.com >> <mailto: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.
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
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
