Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
lorentey opened this issue Jan 17, 2017 · 0 comments
Milestone

Comments

@lorentey
Copy link
Collaborator

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).

@lorentey lorentey added this to the 5.0 milestone Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant