> On 19 Dec 2016, at 04:10, Dave Abrahams via swift-evolution
> <[email protected]> wrote:
>
>
> on Fri Dec 16 2016, Daniel Vollmer <[email protected]
> <mailto:[email protected]>> wrote:
>
>> Hi,
>>
>>> On 16 Dec 2016, at 14:56, Alexey Komnin via swift-evolution
>>> <[email protected]> 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
> [email protected] <mailto:[email protected]>
> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
