Lazy collections use the same indexes as their underlying collections, so (as I understand it) it's assumed that if you do direct access using an index, you want an element from the underlying collection. If you want the first element, you can use .first.

@lorentey, does that sound correct?

It does! The lazy filter collection reuses the index type of the original collection, although typically only a subset of the original indices are valid in it. In this case, 0 is an invalid index in lazyCollection; unfortunately the index is just passed through to the underlying collection, with no validation. (Validating the index would involve calling the filter closure, which would be unexpected.)

This wrinkle doesn't occur when using the collection APIs to generate indices in lazyCollection; for example, print(nonLazyCollection[nonLazyCollection.startIndex]) prints 3.

One way to prevent these issues would be to wrap the base collection's indices into a new LazyCollection.Index structure, which could only be generated by LazyCollection's own APIs. @moiseev, do you think we should consider doing that?

I think the main reason they use the underlying collection's index is so that you can use things like index(where:) on the lazy collection and get something useful. It'd also be pretty source-breaking to change.

Comment by Petro Korienev (JIRA)

While it sounds reasonable, it's really confusing for the developers because:

• Lazy collection isn't documented the way that it passes index through to base collection. To understand this developer needs to go and study sources like https://github.com/apple/swift/blob/swift-4.1-branch/stdlib/public/core/Filter.swift#L350
  • Since lazy collections are non-destructive, it's intuitive to think that subscripting will run lazy calculation chain instead of passing index through to base.

The possible solution will be to run complete lazy calculation chain once:

• startIndex/endIndex/formIndex is accessed

• subscript is accessed

and then cache the result into some `_calculated` property discarding `_base` collection?

If changes to LazyCollection are off the roadmap for Swift 4.2 minors / Swift 5, probably adding proper documentation for this case can be considered to be taken into implementation?

Thanks in advance

/cc @natecook1000