[swift-evolution] Bike-shedding alternate collections API

[Dave Abrahams]

on Thu Mar 24 2016, Howard Lovatt <swift-evolution at swift.org> wrote:

> _______________________________________________ swift-evolution mailing list swift-evolution at swift.org https://lists.swift.org/mailman/listinfo/
> swift-evolution
>
> Bike-shedding alternate collections API - cut down to keep them short enough to post.
>
> They differ from the current collections API and the new proposed collections API in that:
>
>  1. They use the existing external iterator, 

You mean index.

>     `iterator.next()`, rather
>     than the proposed style, `iterator.next(&i)`, because the new style
>     ties the iterator to a particular collection type and therefore
>     cannot be type erased.

The new style does not prevent type erasure.  See
https://github.com/apple/swift/blob/swift-3-indexing-model/stdlib/public/core/ExistentialCollection.swift.gyb
for an example.

>     Type erasure is required to keep return types generic, e.g. rather than
>     map returning an Array it returns an `AnyNextorable<Element>` (see point 5 below).
>  2. The protocols are not, in general, heirarchical; instead they are small building blocks at the top level that can be fitted together.
>  3. Protocols are split when a good default implementation cannot be provided, e.g. CountableCollection is seperate because the default of iterating and
>     counting the elements is not a good implimentation of count.
>  4. Hierarchies are used for convenience, e.g. ArrayCollection is a convenience protocol that extends base protocols.
>  5. The protocol member's return generic implementations of protocols, e.g. where you might return an Array instead you return an `AnyNextorable<Element>`.
>     This sidesteps issues with associated types and generics and prevents large type signatures. The downside is that you have comitted to a particular
>     interface and therefore lost covariance. When generics are completed hopefully these return types can be replaced with `Any<... where ...>`, e.g. `Any
>     <Nextorable where Element == Element>`
>  6. LazyNextable is split out seperately so that the semantics of lazy are articulated in the type system. The design of LazyNextable is also compatible
>     with adding ParallelLazyNextable in the future.
>  7. The naming of the protocols is one of:
>      1. Xxxable because it is a main behavioural protocol and its main member is xxx, e.g. Nextorable has a main property nextor.
>      2. If in the rare case that a protocol extends another protocol then the new property is prepended, e.g. MutableSubstriptable extends Substriptable
>         and the main method added is mutable subscripting.
>      3. If they don't have a main member then they are named after what they are used for, e.g. ArrayCollection defines the members of Array like
>         collections. Note name format of XxxCollection.
>      4. AnyXxxx is a type erased implimentation of Xxx, e.g. AnyLazyNextable is an erased LazyNextable.
>      5. Xxxee and xxxee is used for the subject of an action, e.g. Rangee is a collection of methods that a type must impliment to be used in a Range.
>  8. Range has an Int index of 0 to count - 1 and a value of start + index * stride, where start and stride are of type Rangee. Int and Double via extension
>     are made Rangees.
>  9. Index, used in Subscriptables, can be any type.

Let's cut to the chase: what problem are you trying to solve, and how
does your proposal address that problem?

-- 
Dave