[swift-evolution] Changes to RangeReplaceableCollectionType

[Haravikk]

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:

Remove initialisers

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.

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.

Separate out the append(), appendContentsOf() and reserveCapacity() methods:

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.

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.

Separate removal and insertion:

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).


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160228/f02942cc/attachment.html>