<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On May 9, 2016, at 9:48 PM, Joe Groff via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">On May 9, 2016, at 6:23 PM, Brent Royal-Gordon via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""><blockquote type="cite" class="">* Operations that depend on sorted-ness and use binary predicates should<br class="">not be available on all Collections; they're too easy to misuse,<br class="">they're hard to name well, and as Nicola Salmoria has noted, they<br class="">would not make any sense at all for a Set&lt;T&gt;.<br class=""><br class="">* They should be scoped to a kind of collection that bundles<br class="">the predicate with the elements, e.g.<br class=""><br class="">&nbsp;let x = Sorted([3, 4, 1, 5, 2], &gt;) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// stores a sorted copy of the array<br class="">&nbsp;let y = Sorted(preSorted: 0..&lt;100, &lt;) &nbsp;// stores a copy of the range<br class=""><br class="">Maybe there should also be protocols for this; CountableRange&lt;T&gt; would<br class="">already already conform to the immutable version. &nbsp;We might want a<br class="">mutable form of the protocol for sorted collections with<br class="">insertion/removal methods. &nbsp;This whole area needs more design.<br class=""></blockquote><br class="">I agree with both of these statements, but not with your conclusion.<br class=""><br class="">There are three classes of collections:<br class=""><br class="">1) Those which are always sorted, like a SortedSet.<br class="">2) Those which may or may not be sorted, like an Array.<br class="">3) Those which are never sorted, like a Set.<br class=""><br class="">These APIs are useless on a #3, but #2 is still a valuable use case to support. In particular, it's quite common to use sorted `Array`s, and these APIs would help you do that.<br class=""><br class="">What I might consider doing is tying this to `RangeReplaceableCollection`. That protocol is applied only to types which allow insertion at arbitrary indices, which is a good, though not perfect, proxy for types which might allow you to manually maintain a sort order. `Array`, `ArraySlice`, `ContiguousArray`, and the mutable `String` views would get these methods, while `Set` and `Dictionary` would not.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">We could also introduce a new OrderedCollection protocol. (This would also be useful in the future for supporting `case` pattern matching on collections. It makes sense to pattern-match arrays and other ordered collections in order by element, but you'd expect very different semantics pattern-matching an unordered Set.)</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><blockquote type="cite" class=""><br class=""></blockquote></div><div><blockquote type="cite" class=""><span class="" style="float: none; display: inline !important;">-Joe</span><br class=""></blockquote><br class=""></div><div>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. index(where:) was marginally useful with dictionaries, but now that Sequence is getting first(where:), née find(...), even that isn't necessary.</div><div><br class=""></div><div>Nate</div><div><br class=""></div></div></body></html>