<div dir="ltr">Why is the protocol for iterators called IteratorProtocol instead of Iterator or Iterable? If that is/was discussed elsewhere, I apologize, but I don't remember seeing that particular name before. Is that new to this proposal?</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 1, 2016 at 9:04 PM, Dmitri Gribenko 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">Hi,<br>
<br>
We would like to propose a major change to how collection indices<br>
work. The standard library team has discussed this idea internally<br>
and we wrote a prototype. Now we think it is a viable direction to<br>
consider, and we are bringing it for wider public discussion.<br>
<br>
I'm pasting the first section of the proposal below to give you a<br>
general idea about this change, but please read the proposal to<br>
understand the full details.<br>
<br>
You can find the most up to date version of the proposal at<br>
<a href="https://github.com/gribozavr/swift-evolution/blob/new-collections/proposals/NNNN-collections-move-indices.md" rel="noreferrer" target="_blank">https://github.com/gribozavr/swift-evolution/blob/new-collections/proposals/NNNN-collections-move-indices.md</a><br>
<br>
Permalink: <a href="https://github.com/gribozavr/swift-evolution/blob/87df19a9a9d73e64a2a966b807440216a608b8ad/proposals/NNNN-collections-move-indices.md" rel="noreferrer" target="_blank">https://github.com/gribozavr/swift-evolution/blob/87df19a9a9d73e64a2a966b807440216a608b8ad/proposals/NNNN-collections-move-indices.md</a><br>
<br>
Dmitri<br>
<br>
## Introduction<br>
<br>
We are proposing a new model for collections, where indices can only be<br>
advanced forward or backward by the corresponding collection instance.<br>
Indices become opaque tokens representing collection positions, that can<br>
be produced and consumed by collection APIs. This allows us to reduce<br>
the amount of data stored in indices to the bare minimum.<br>
<br>
Compared to the current state, the new scheme simplifies implementation<br>
of non-trivial indices, and fixes concurrency issues in `Set` and<br>
`Dictionary` indices. It also allows us to eliminate reference-counted<br>
stored properties from most indices, including non-trivial ones, like<br>
`Set.Index` and `Dictionary.Index`, creating more optimizable code.<br>
<br>
Out of scope for this proposal:<br>
<br>
* Expanding the set of concrete collections provided by the standard<br>
library.<br>
<br>
* Expanding the set of collection protocols to provide functionality<br>
beyond what is already provided (for example, protocols for sorted<br>
collections, queues etc.) Discussing how other concrete collections<br>
fit into the current protocol hierarchy is in scope, though.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>>*/<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>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Trent Nadeau</div>
</div>