[swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Howard Lovatt]

Review of:
https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md

* What is your evaluation of the proposal?

I think it is a big improvement over the current collections API. However I
have a number of reservations, particularly:


   1. The motivation of improved performance smacks of "premature
   optimisation". For particularly high performance collections a fast unsafe
   form could be provided, like UnsafePointer, e.g. UnsafeArray. For the rest
   I think it is better to have a clean API rather than skew the API for
   performance.
   2. The proposed iterator, `collection.next(&iterator)`, is not as
   convenient to use as a classic external or internal iterator. It introduces
   the potential for errors where an iterator from one collection is used in
   another and where the collection and iterator are manipulated separately.
   What's the point of eliminating C for loops because of index problems and
   then introducing much the same? The new iterator cannot be type erased
   without also capturing the associated collection, defeating the point of
   the new iterators!
   3. The protocols are quite hierarchical; instead they could be a
   collection [sic] of small, top-level protocols that are plugged together. A
   useful division is one main method per protocol with 'good', default
   implementations provided for other methods. A 'good' implementation of
   count would not be iterating through the collection counting!
   4. The members, e.g. map, filter, return specific implementations like
   Array. I find this restrictive. Would it be possible to return a protocol
   to allow other implementations more flexibility.
   5. There is an advantage in splitting lazy into a separate hierarchy,
   there is precedence for this in that both Java, Stream, and C#, LINQ, do
   this. The main differences are that you would expect a collection to be
   multiple iterable, e.g. inside a nested loop, and mutable, e.g.
   subscriptable, whereas a lazy can only be guaranteed to be iterable once
   and is purely functional. This splitting of lazy into a separate API would
   also lay the groundwork for a parallel-lazy version.
   6. The naming of the protocols would be better if they were Xxxable and
   that xxx referred to the main method in the protocol. For example instead
   of Sequence, Iterable because its key feature is iterate.
   7. I think Range would be better if it has an Int index of 0 to count -
   1 and a value of start + index * stride, where start and stride are of type
   Arithmetic, i.e. range[index] = start + index * stride.


* Is the problem being addressed significant enough to warrant a change to
Swift?

Yes the current collections API could be improved and it is an important
part of any programming language.

* Does this proposal fit well with the feel and direction of Swift?

In some ways yes, it captures more of your intention in the type system.
But in other ways no, it introduces an iterative paradigm that is
potentially more error prone that the existing one and step back towards
using subscripts and index for everything, ie. C for loop style.

* If you have you used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?

Obviously everyone uses collection API's in every language. I have used
collections in many diverse languages and also written custom collections,
e.g. a parallel collection API in Java before Java got a standard version.

* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

Quite a bit, including fleshing out a minimal collection API that conforms
to the principles stated above and posted on swift-evolution under the new
iterator model discussions.

  -- Howard.

On 11 April 2016 at 07:41, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> Hello Swift community,
>
> The review of "A New Model for Collections and Indices" begins now and
> runs through April 18th. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md
> <https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md>
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at:
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change to
> Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have you used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160416/36e6fa77/attachment.html>