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

[Howard Lovatt]

Sorry, unfortunately I can't see that it really helps. All that happens is
that the client of the collection now holds the reference to the collection
as well as the reference to the iterator. In the more traditional model the
client holds a reference to the iterator which in turn holds a reference to
the collection.

Maybe the problem arose with the double indirection trick. Would a better
approach be to keep it simple:

    struct SomeCollection<E>: Collection {
        private var refToInternalStorage: UnsafePointerOfSomeSort<E>
        func iterable() -> SomeCollectionIterator { return
SomeCollectionIterator(self) }
        mutating func append(element: E) {
            copyInternalStorageIfNecessary(size + 1) // Makes a copy if
either not large enough or if already aliased
            // Append `element` to `refToInternalStorage`
        }
        // Other functions access `refToInternalStorage`, but if mutating
call `copyInternalStorageIfNecessary(Int)` before modifying
    }

    struct SomeCollectionIterator<E>: Iterator {
        private let someCollection: SomeCollection<E> // Note let not var -
could be direct link to internal storage
        private var index: Index
        init(someCollection: someCollection <E>) {
            self.someCollection = someCollection
            index = someCollection.firstIndex()
        }
        // next()
    }

Obviously above is pseudo code - but hopefully you get the idea.

The difference comes when with the proposal you do:

    var array = [1]
    var iterator = array.makeIterator()
    array.removeAll()
    array.next(iterator) // Runtime exception

Similarly with modifications in another thread. With the above suggested
`obvious` implementation:

    var array = [1]
    var iterator = array.iterator()
    array.removeAll()
    iterator.next() // OK, returns 1 because it has the original before
array was mutated.

In essence I am saying do the obvious, since that is easiest for the
clients (i.e. the programmers that use Swift).

Sorry to be negative,

 -- Howard.

  -- Howard.

On 2 March 2016 at 14:03, Trent Nadeau via swift-evolution <
swift-evolution at swift.org> wrote:

> Ah. Thanks. I've read through that proposal before but totally forgot that
> change.
>
> On Tue, Mar 1, 2016 at 10:01 PM, Dmitri Gribenko <gribozavr at gmail.com>
> wrote:
>
>> On Tue, Mar 1, 2016 at 6:55 PM, Trent Nadeau <tanadeau at gmail.com> wrote:
>> > 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?
>>
>> I'm using the new names introduced by SE-0006
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md
>>
>> The protocol is not called Iterator to disambiguate it with the
>> Iterator associated type in Sequence from the protocol:
>>
>> protocol Sequence {
>>   associatedtype Iterator : IteratorProtocol
>> }
>>
>> It is not called Iterable because that would have the wrong meaning
>> (Sequence is iterable, the iterator iterates over its elements).
>>
>> Dmitri
>>
>> --
>> 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>*/
>>
>
>
>
> --
> Trent Nadeau
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160302/96d342b0/attachment.html>