<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 class=""><div class="">On the one hand, I agree with your assessment (I’ve also done various order-maintaining collections, and based on that I think you’ll find *neither* `RangeReplaceableCollectionType` nor `MutableCollectionType` are actually adoptable for your type; the “weaker" `MutableCollectionType` isn’t even adoptable by `Set` and `Dictionary` as it requires ordered, freely-reorderable storage).</div><div class=""><br class=""></div><div class="">But, on the other hand, I’m not sure there’s actually a meaningful version of `RangeReplaceableCollectionType` that’d make sense for an order-maintaining collection, anyways, for the reasons you outlined in “Separate removal and insertion”; the API seems entirely inappropriate outside of the `remove*` functions, as you noted (FWIW it seems *mostly* meant to support things like ropes and other, similar data structures).</div><div class=""><br class=""></div><div class="">I’d expect a generic ordered-collection protocol to have methods more like this:</div><div class=""><br class=""></div><div class=""><div class=""><div class="">// some example removal methods:</div><div class="">mutating func removeElementsWithin(interval: ClosedInterval<Element>) // <- requires `Element:Comparable`</div><div class="">mutating func removeElementsBefore(element: Element) </div><div class="">mutating func removeElementsAfter(element: Element) </div></div></div><div class=""><br class=""></div><div class="">…(e.g., functions that actually reference/take advantage of the ordering), and there’s actually rather a lot of methods that would *potentially* be useful things to have and override.</div><div class=""><br class=""></div><div class="">I’m a bit curious if anything other than (perhaps?) “Collections move Indices” is on tap for standard-library updates on this topic (e.g. any plans for a baked-in “OrderedCollection” protocol, or for tree-shaped collections, etc.?).</div><div class=""><br class=""></div><div class=""><div class="">PS: FWIW, I’ve found the best way to handle “ordered collections” at present is to make it so it “has-a” (read-only) collection, but is *not* itself a collection…for read-only use this doesn’t change much, and as already noted the mutable-collection protocols are rather troublesome here.</div></div></div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 28, 2016, at 11:47 AM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">So today I’ve been trying to put together an implementation of an ordered collection, and I noticed that a lot of important mutating methods are actually grouped together under RangeReplaceableCollectionType, which is actually kind of weird, and has led me to create some more specialised protocols of my own as I actually can’t implement RangeReplaceableCollectionType as it for a number of reasons, which I’ll discuss here:<div class=""><br class=""></div><div class=""><b class="">Remove initialisers</b></div><div class=""><b class=""><br class=""></b></div><div class="">I’m not actually sure why RangeReplaceableCollectionType has required initialisers, since it shouldn’t really matter how you create it since you can reserve capacity separately if you have to, prior to dumping elements into it. However, having these initialiser requirements actually makes it impossible to conform to this protocol if you require other data in order to initialise your type.</div><div class=""><br class=""></div><div class="">For example, my type requires a closure, and I can’t provide a default closure (since the whole point of it is so I can support elements of any type). I can’t think of any reason why these initialiser requirements should be necessary, so hopefully they can just be removed.</div><div class=""><br class=""></div><div class=""><b class="">Separate out the append(), appendContentsOf() and reserveCapacity() methods:</b></div><div class=""><b class=""><br class=""></b></div><div class="">These methods don’t seem to me to be specific to RangeReplaceableCollectionType, and it seems like they should be separated into an AppendableCollectionType or ExpandableCollectionType or similar. While .replaceRange() could technically be used to fulfil .append() and .appendContentsOf(), it’s not actually replacing anything so it isn’t directly related IMO.</div><div class=""><br class=""></div><div class="">Indeed, it’s conceivable that a type might want to declare the ability to append elements separately from declaring means of removing them arbitrarily (which is what RangeReplaceableCollectionType does), as they may want stricter requirements on removal; for example a queue where elements can only be removed via a removeHead() method or similar.</div><div class=""><br class=""></div><div class=""><b class="">Separate removal and insertion:</b></div><div class=""><b class=""><br class=""></b></div><div class="">Another case where RangeReplaceableCollectionType forces potentially incompatible actions is that it requires both the ability to remove and to insert arbitrarily into a collection. This is fine if the collection has no form of sort order, however, if the collection is sorted, then insertion operations actually make no sense, requiring the type to ignore the provided indices and just position elements where it decides is best regardless. Removals from a sorted collection don’t have this issue however (if you remove a chunk from them then the remaining elements should still be in the correct order).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Essentially this is a bunch of issues I ran into while attempting to implement an ordered collection with as many of the same capabilities of an Array as possible; while I realise that separation will result in two new CollectionType protocols, I think that it could be beneficial for flexibility when defining our own custom types.</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>