> On Apr 13, 2016, at 5:34 AM, Haravikk <[email protected]> wrote: > > >> On 13 Apr 2016, at 04:46, plx via swift-evolution >> <[email protected]> wrote: >> >> Invalidation is hard and I wouldn’t want anything held up to try and find a >> solution first. > > Oh I agree, that was partly my point though; while this proposal may leave us > with the "un-Swifty" issue of being unable to explicitly handle invalidation, > it should be possible to solve that later, i.e- this proposal does’t make us > any more vulnerable to that problem than we are now, but I definitely agree > that we could do with some kind of invalidation mechanism in future that > developers can actually implement or respond to. I guess I was more thinking > out loud about whether the problem affects the proposal or not, but I don’t > think that solving it will place any restrictions on the API as proposed, > definitely deserves a proposal of its own once the new indexing system is in > place though!
There was a design document linked in one of the earlier discussions that IIRC suggested some collections would want to maintain a "revision count” value, with their indices then holding a snapshot of that “revision count” at their time of creation. For something like Array that’s a bit heavyweight. “Invalidation" is also IMHO a bit under-defined without an associated “for what?”: var letters = [“a”, “b”, “c”, “d”, “e”] // indexOfB == 1 let indexOfB = letters.indexOf(“b”) letters.insert(“z”, atIndex: indexOfB) …is `index` invalid or not? IMHO it would depend on what you want to do with it. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
