on Thu Mar 24 2016, Howard Lovatt <[email protected]> wrote:
> _______________________________________________ swift-evolution mailing list > [email protected] 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
