I'm not sure about the rest of this, but... >> 1. A backwards-compatible refactoring of `CollectionType.indices`, moving it >> to `Indexable`. >> >> 2. A backwards-compatible refactoring of `indexOf(…)` (adding optional >> `range:` and moving it to `Indexable`). >> >> 3. The addition of `rangeOf(…)`, `countOf(…)` and `isSorted(…)` to >> `Indexable` with a TIME complexity of `O(self.count)`. >> >> 4. The introduction of a `BinarySearchView` on `Indexable`, allowing for >> fast (`O(log2(self.count))`) searches on `Indexable` via `indexOf(…)`, >> `rangeOf(…)`, `countOf(…)`, `lowerBoundOf(…)`, `upperBoundOf(…)` without >> cluttering `Indexable`'s interface.
I don't think you quite understand what `Indexable` is for. `Indexable` is a minimal protocol containing the very most basic parts of `CollectionType`'s interface. It's used to avoid circular definitions in `CollectionType`. The doc comments on it describe it as "almost an implementation detail". I don't think it's appropriate to move a whole bunch of stuff into `Indexable` when it's supposed to be a minimal protocol. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
