[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