I don't think we want to pay the cost of validating the index, but I guess we could. @airspeedswift?

Right. This would be a big perf hit because you would, on subscript access, have to execute the predicate a second time, which might be costly. I think I'd consider this behaves-correctly. We could perhaps add an assert in debug builds.

Comment by Jens Jakob Jensen (JIRA)

I guess it would help if this was documented for the LazyFilterCollection.

I actually first thought that a lazy collection was memoizing. Are there any plans to add a memoizing LazyCollection? Then each element would only be created once. So if you did evens[3], then the first elements 1...8 of the underlying array in the case above would be consumed and wouldn't be accessed anymore. The point of course would be that the lazy closures could be costly, so ensuring that they were only run once could make sense.

We have a method taking a LazyConnection instead of a factory closure. I was surprised when the "factory closure" (i.e. a lazy map closure) was executed several times because the client used .lazy.compactMap() and we first accessed .count() then traversed the lazy collection 🙂

Comment by Jens Jakob Jensen (JIRA)

Actually IMHO every aspect where adding .lazy makes the collection behaving differently would be great to have documented. I would consider any non-documented change in semantics bugs.

The documentation of LazyFilterCollection states "A sequence whose elements consist of the elements of some base sequence that also satisfy a given predicate.". I think it would be fair to assume that either the "sequence" did not have a subscript operator, or that the subscript operator behaves as if not using lazy.