[swift-evolution] Changes to RangeReplaceableCollectionType

[Dmitri Gribenko]

On Sun, Feb 28, 2016 at 9:47 AM, Haravikk via swift-evolution
<swift-evolution at swift.org> wrote:
> 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.

If your type absolutely requires non-zero data elements for an
instance to exist, how would it implement removeAll()?

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

Could you provide more information about your type?  If the closure is
a crucial part of the value, how do you implement collection equality?

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

We had ExtensibleCollection before, but we dropped it.  The rationale
is that if you can create an empty collection, and can append, then
you can implement replaceRange() with just that.  Thus,
ExtensibleCollection and RangeReplaceableCollection are the same type.

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

Then your type is not a RangeReplaceableCollection, it is a Queue, or
something else that we don't have.

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

Could you provide more information about the semantics of your
collection, and supported operations?

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/