[swift-evolution] [Proposal]: Drastically improve searching API (indexOf(…)) of CollectionType
griotspeak at gmail.com
Mon Jan 4 17:58:51 CST 2016
The proposed additions to Indexible only require Indices… I don't see how
adding them is such a mistake. If we can gain these behaviors while only
*requiring* that minimum interface… go for it.
On Mon, Jan 4, 2016 at 3:49 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:
> 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
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution