[swift-evolution] Changes to RangeReplaceableCollectionType

[Dmitri Gribenko]

On Mon, Feb 29, 2016 at 1:13 PM, Haravikk <swift-evolution at haravikk.me> wrote:
>
> On 29 Feb 2016, at 11:11, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>
> On Mon, Feb 29, 2016 at 2:54 AM, Haravikk <swift-evolution at haravikk.me>
> wrote:
>
> How would you decide equality?  You would have two collections, one on
> the left, and one on the right, and each of those has a different
> concept of equality via the stored 'isOrderedBefore' closure.
>
>
> To me two collections are equal so long as their contents are the same, and
> in the same order. In other words the actual closure isn’t necessary to the
> comparison, though obviously it will affect it, since elements stored in
> ascending numeric order clearly won’t match the same elements in descending
> numeric order.
>
> I'm not opposed to adding a new protocol.  What seems strange to me is
> that you are describing various collections that clearly can't
> implement RangeReplaceableCollection, and trying to weaken protocol's
> guarantees so that they can.
>
>
> I’m not trying to weaken its guarantees; the only thing directly affecting
> RangeReplaceableCollectionType would be removing the initialisers, as I
> don’t think they’re necessary to implementing that type (though of course I
> welcome any description as to why they may be necessary).
>
> Otherwise a new protocol is exactly what I’m interested in; you mentioned an
> ExpandableCollectionType, which I think is a start, though it should
> probably have add() and addContentsOf()

Set calls this operation 'insert'.

> methods rather than appends (this
> way they place no guarantees on where elements will go, only that they are
> added). While the add() method would be a synonym of append() for arrays, it
> would be useful for aligning with Set I think.
>
> Moving the removeRange() and related methods (removeAtIndex etc.) would take
> them away from RangeReplaceableCollectionType (it should extend whatever new
> protocol is added), but the idea is to separate the concept of removing
> things by index, and replacing them/performing insertions.
>
> Basically I’d like to tweak the protocols such that a generic collection can
> be expanded, and its elements accessed in an order, but that order may be
> defined by the type itself; to me, inserting a value directly at a specific
> index is a more specialist type.

Sound like a plan.  Please make sure to design the protocol in such a
way that there are useful generic algorithms that can be written over
such a protocol.

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>*/