<div dir="ltr"><div style="font-size:12.8px">Review of:</div><div style="margin:0px;font-size:10px;font-family:Monaco"><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md</a></div><div style="margin:0px;font-size:10px;font-family:Monaco"><br></div><span style="font-size:12.8px;white-space:pre-wrap"> </span><span style="font-size:12.8px">* What is your evaluation of the proposal?</span><div><br></div><div>I think it is a big improvement over the current collections API. However I have a number of reservations, particularly:</div><div><br></div><div>
<p class=""></p><ol><li>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.</li><li>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! <br></li><li>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!<br></li><li>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.<br></li><li>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.<br></li><li>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.</li><li>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.</li></ol><p></p><p class=""><span class=""></span></p></div><div><span style="font-size:12.8px;white-space:pre-wrap"><br></span></div><div><span style="font-size:12.8px;white-space:pre-wrap"> </span><span style="font-size:12.8px">* Is the problem being addressed significant enough to warrant a change to Swift?</span><div><span style="font-size:12.8px"><br></span><div>Yes the current collections API could be improved and it is an important part of any programming language.</div><div><br style="font-size:12.8px"><span style="font-size:12.8px;white-space:pre-wrap"> </span><span style="font-size:12.8px">* Does this proposal fit well with the feel and direction of Swift?</span></div><div><br></div><div>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.</div><div><br style="font-size:12.8px"><span style="font-size:12.8px;white-space:pre-wrap"> </span><span style="font-size:12.8px">* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span></div><div><br></div><div>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.</div><div><br style="font-size:12.8px"><span style="font-size:12.8px;white-space:pre-wrap"> </span><span style="font-size:12.8px">* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span><br></div></div></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"> -- Howard.<br></div></div>
<br><div class="gmail_quote">On 11 April 2016 at 07:41, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hello Swift community,<br><br>The review of "<span style="color:rgb(4,51,255);font-family:Menlo;font-size:11px">A New Model for Collections and Indices</span>" begins now and runs through April 18th. The proposal is available here:<br><br><span style="white-space:pre-wrap"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md</a><br><br>Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:<br><span style="white-space:pre-wrap"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>or, if you would like to keep your feedback private, directly to the review manager.<br><br><br>What goes into a review?<br><br>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:<br><br><span style="white-space:pre-wrap"> </span>* What is your evaluation of the proposal?<br><span style="white-space:pre-wrap"> </span>* Is the problem being addressed significant enough to warrant a change to Swift?<br><span style="white-space:pre-wrap"> </span>* Does this proposal fit well with the feel and direction of Swift?<br><span style="white-space:pre-wrap"> </span>* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br><span style="white-space:pre-wrap"> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br><br>More information about the Swift evolution process is available at<br><br><span style="white-space:pre-wrap"> </span><a href="https://github.com/apple/swift-evolution/blob/master/process.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a><br><br>Thank you,<br><br>-Chris Lattner<br>Review Manager</div><div><br></div><div><br></div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>