[swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

Nate Cook nate at natecook.com
Fri May 13 11:07:07 CDT 2016


>> On May 13, 2016, at 9:36 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> on Mon May 09 2016, Nate Cook <natecook-AT-gmail.com> wrote:
>> 
>> Yet another alternative would be to drop Set and Dictionary down a
>> level to a FiniteSequence protocol in between Sequence and
>> Collection. Basically none of the index-based collection APIs
>> (i.e. everything except `count` and `isEmpty`) make sense on sets and
>> dictionaries.
> 
> Strongly disagreed.  Any read-only operation that makes sense on a
> bidirectional collection makes sense on these data structures.

I don't see how the methods that impose meaning on the order of a set are useful. What does mySet.prefix(upTo: i) mean when I have no control or dependable way of knowing which elements lie between startIndex and i? mySet.first is useful, but it's meaning is more like NSSet's anyObject.

>> index(where:) was marginally useful with dictionaries, but now that
>> Sequence is getting first(where:), née find(...), even that isn't
>> necessary.
> 
>   s.remove(at: s.index(where: { $0 < 1 }))

Since Set's remove(at:) method is type-specific, it would need to be rewritten as remove(where:). 

This example is kind of my point, though - it removes the first element less than 1, but only one such element, and there's no telling which. That's not an operation I've ever needed to perform on a set.

To clarify, I don't think the current system is hurting Set and Dictionary in any way. It's simply providing them with methods that aren't very useful for that particular data structure.

Nate

> -- 
> -Dave
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list