[swift-evolution] Add ability to validate collection indices

Karl razielim at gmail.com
Mon Dec 19 09:16:06 CST 2016


> On 19 Dec 2016, at 04:10, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Fri Dec 16 2016, Daniel Vollmer <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> Hi,
>> 
>>> On 16 Dec 2016, at 14:56, Alexey Komnin via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> [snip]
>> 
>>> What do you think? I feel, like we should discuss it before I
>>> formalize it as a proposal.
>> 
>> I think this is a fruitless attempt, as even if the indices are still valid,
>> they may not refer to the same elements they referenced before the mutation.
>> 
>> Of course, mutating methods should state whether the invalidate existing
>> indices, but I think that’s about the best that can be reasonably
>> done.
> 
> We can do a bit more.  For example, RangeReplaceableCollection's
> replaceRange should return the range in the new collection state
> corresponding to the elements that were replaced.  
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
Oh, we really do. It’s not such a big deal for Array and basic collections, but it’s absolutely essential for String (where a character index may represent a variable number of bytes).

I think the way to resolve this would be to return some kind of IndexDisplacement type which knows how the underlying indexes were mutated (e.g. "100 bytes added at offset 36”) so it can transform previously-valid indexes in to indexes which are valid post-mutation. See: https://bugs.swift.org/browse/SR-2689 <https://bugs.swift.org/browse/SR-2689>

- Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161219/2138c3d4/attachment.html>


More information about the swift-evolution mailing list