[swift-evolution] Bike-shedding alternate collections API

Dave Abrahams dabrahams at apple.com
Thu Mar 24 19:26:56 CDT 2016


on Thu Mar 24 2016, Howard Lovatt <swift-evolution at swift.org> wrote:

> Detailed comments about iterator inline below.
>
> Big picture is:
>
> Separating lazy collections from eager collection with a view to a future world with lazy parallel collections.
> Returning AnyXxx rather than a specific type to both keep types short and to be more flexible.
> Removing constraints on Index, useful for linked lists etc.
> Changing the way Range works to that it plays nicer with a larger range of types; range[index] = start + index * stride
> Flattening the hierarchy, to allow a mix and match approach to features for more flexibility.
>
> Saying problem to be solved is too strong. There is no real problem
> with the current collections. They work just fine. However I think
> they could be finessed. Much like many of the things discussed on
> swift-eveolution :(
>
>> On 25 Mar 2016, at 8:28 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Thu Mar 24 2016, Howard Lovatt <swift-evolution at swift.org> wrote:
>> 
>>> _______________________________________________ swift-evolution
>>> mailing list
>>> swift-evolution at swift.org
>>> 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.
>
> For the proposed new collections you would write:
>
>     var iterator = array.iterator
>     let element = array.next(&iterator)

In your proposal?  That's not what we're intending to bring forward.


-- 
Dave



More information about the swift-evolution mailing list