Answer.

Lazy Collections are a special mechanism introduced in Swift 2 that allows postponing computations over collections until the moment of actual access to the result. Initially, standard collection methods (like map, filter) returned a fully computed result of a new collection, which sometimes led to unnecessary memory and time costs, especially when dealing with large arrays or chains of transformations.

The Problem lies in the excessive creation of intermediate collections. Each call to map or filter creates a new copy of the data, which can significantly degrade the performance of the program with multiple transformations.

The Solution is to use lazy collections via the .lazy property. Swift combines all operations into a single chain and computes only those elements which are actually accessed.

Code example:

let array = Array(1...1_000_000)
let result = array.lazy.filter { $0 % 2 == 0 }.map { $0 * 3 }
print(result.prefix(5)) // Only the first 5 values will be computed

Key features:

Computation occurs only when accessing an element (on-demand).
No intermediate arrays are created in map/filter chains.
Saves memory and time on large data.

Tricky Questions.

Question 1: Does let b = a.lazy.map { ... } immediately return the computed result?

No, when using .lazy with map/filter methods, the computed result is returned only when actually accessing the data (for example, through for-in, first, reduce).

Code example:

let array = [1, 2, 3]
let mapped = array.lazy.map { x in
    print("processing\(x)")
    return x * 2
}
// At this point nothing will be printed
let first = mapped.first // This is when the computations will start and output will appear

Question 2: Can you add a new element to the original collection after .lazy and will it also be processed if you access the result later?

No, a Lazy Collection reflects the state of the collection at the time of creating the lazy view. Later added elements will not be taken into account.

Question 3: Is using .lazy effective for small collections (<100 elements)?

No, for small collections, the gain from lazy computations is virtually negligible, and sometimes the extra overhead negatively impacts performance.

Common Mistakes and Anti-Patterns

Forgetting to access the result of the lazy chain and thinking that the data has already been computed.
Using .lazy on small arrays, complicating the code without gaining any performance benefits.
Modifying the original collection after creating the lazy view and expecting the changes to be picked up.

Real-life Example

Negative Case

In the project, .lazy was thoughtlessly used for all map/filter even on small collections.

Pros:

Unification of code style.

Cons:

Performance decreased due to constant creation of lazy wrappers.
Bugs appeared: computations were not performed and data was not processed in time.

Positive Case

Refactored reports for a large transaction database using .lazy only for functions where there were indeed long chains of transformations.