[swift-evolution] [RFC] New collections model: collections advance indices

[plx]

# General Remarks: Great!

Thanks for sharing this proposal; it's a big change, but will be a big improvement once it's in place, and it's encouraging to see the team is willing to undertake changes of such scale.

I'm not sure how much discussion you'll actually manage to scare up b/c the issues this proposal addresses are *not* common, but are nevertheless rather significant when encountered.

E.G.: it's nice to be able to create simple chain/product/etc. collection-combinators which can, themselves, be collections, without winding up with indices indices forced to choose between *either* holding a back-reference to retrieve various startIndex/endIndex values as-needed *or* carrying around a complete set of all needed startIndex/endIndex values.

I don’t have any negative feedback that isn’t subsumed by the next section.

# Concern: Linearity Baked-In 

Even with this change, I have some concern that the proposed protocol hierarchy from `Collection` onward feels like it has a foreseeable lack of generality due to how strongly "linear" the design wants `Collection` to be. 

Is this the right time to raise such concerns (e.g. in-scope for this discussion)?

Other than that concern about generality I think this proposal looks great "on paper” and I hope to get a chance to experiment with it soon.

> On Mar 1, 2016, at 8:04 PM, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi,
> 
> We would like to propose a major change to how collection indices
> work.  The standard library team has discussed this idea internally
> and we wrote a prototype.  Now we think it is a viable direction to
> consider, and we are bringing it for wider public discussion.
> 
> I'm pasting the first section of the proposal below to give you a
> general idea about this change, but please read the proposal to
> understand the full details.
> 
> You can find the most up to date version of the proposal at
> https://github.com/gribozavr/swift-evolution/blob/new-collections/proposals/NNNN-collections-move-indices.md
> 
> Permalink: https://github.com/gribozavr/swift-evolution/blob/87df19a9a9d73e64a2a966b807440216a608b8ad/proposals/NNNN-collections-move-indices.md
> 
> Dmitri
> 
> ## Introduction
> 
> We are proposing a new model for collections, where indices can only be
> advanced forward or backward by the corresponding collection instance.
> Indices become opaque tokens representing collection positions, that can
> be produced and consumed by collection APIs.  This allows us to reduce
> the amount of data stored in indices to the bare minimum.
> 
> Compared to the current state, the new scheme simplifies implementation
> of non-trivial indices, and fixes concurrency issues in `Set` and
> `Dictionary` indices.  It also allows us to eliminate reference-counted
> stored properties from most indices, including non-trivial ones, like
> `Set.Index` and `Dictionary.Index`, creating more optimizable code.
> 
> Out of scope for this proposal:
> 
> * Expanding the set of concrete collections provided by the standard
>  library.
> 
> * Expanding the set of collection protocols to provide functionality
>  beyond what is already provided (for example, protocols for sorted
>  collections, queues etc.)  Discussing how other concrete collections
>  fit into the current protocol hierarchy is in scope, though.
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution