attaswift / BTree

Fast sorted collections for Swift using in-memory B-trees

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Slices of BTree collections do not share indices with the original collection

lorentey opened this issue · comments

Swift's Collection protocol has a number of nontrivial semantic constraints that are rather under-documented; one of these is that a collection's SubSequence must be a collection that shares indices with the original instance. (The type system is currently not even able to enforce the requirement about SubSequence being a collection, or that its index type must be the same as the top-level collection. Presumably, these are going to be fixed, but the requirement about sharing index values is unlikely to be ever enforced by the type system.)

Slices of valid collections should have their start index the same as the index of their starting element in the original collection. BTree gets this wrong:

let list = List(0 ..< 10)
print(list[3 ..< 10].startIndex) // ==> 0
let array = Array(0 ..< 10)
print(array[3 ..< 10].startIndex) // ==> 3

This means BTree's collection types aren't really collections.

The way to fix this is to replace the custom SubSequence typealiases with one of the default Slice types in each. This is a source-breaking change, so it requires a major version bump.

The original BTree slicing behavior (i.e., extracting a separate sub-collection of the same type) will be moved to a family of functions (list.extract(3..<10) or list.sublist(3..<10) or somesuch).