Do higher order functions in Swift respect the order?

Not a coding question but it's something that I couldn't find an answer to.

Do higher order functions like .map(), .filter(), .reduce() respect the order of given collection?

Let's assume that we have an array of integers as follows:

let arrayOfIntegers: [Int] = [1, 2, 3, 4, 5]

Will this line of code always return the same order?

arrayOfIntegers.map { $0 * 2 } // [2, 4, 6, 8, 10]

Is it even possible to have something like [2, 6, 10, 4, 8]?

map(_:), filter(_:), reduce(_:_:), and many other similar higher-order functions are all provided by the Sequence protocol. The purpose of this protocol is for defining a way to iterate through sequences of data, and it provides a wide variety of methods which are implemented in terms of that sequential access through the data.

The order in which a Sequence provides its data is up to it. While many types like Array have a natural order to them, there are other Sequences which do not, like Set or Dictionary. (Note that types like this offer iteration in some consistent order, but the order may be arbitrary.)

The order, then, that your map, filter, and reduce functions will be called in depends on the iteration order of the underlying collection — but in most cases, it will simply be what you expect.

To supplement Itai's existing answer:

If you have this code:

let arrayOfIntegers = [1, 2, 3, 4, 5]
let result = arrayOfIntegers.map { $0 * 2 }
print(result) // [2, 4, 6, 8, 10]

The result is guaranteed^{* kind of} to always be in that order, for the case of Array.map(_:)

What's not guaranteed is that the calls to the closure will happen in any particular order. So if the closure has any side-effects, they might observe a different order. So don't do this:

let arrayOfIntegers = [1, 2, 3, 4, 5]

var sideChannel = [Int]()

let result = arrayOfIntegers.map { i -> Int in
    sideChannel.append(i * 10) // ⚠️ Don't put side effects in calls to `map` like this.
    return i * 2
}
print(result) // [2, 4, 6, 8, 10]
print(sideChannel) // [10, 20, 30, 40, 50], but the order is not guaranteed

That's mostly a theoretical concern, however. It's very unlikely to change. Still, don't rely on it.

* ^{The example in the docs implies the ordering is guaranteed, but I don't see any explicit language guaranteeing the 1-to-1 correspondence between input and output elements. However, changing the ordering would be an absolute shitshow, because of all the existing code that depend on it.}

Other people are telling what the situation is, for unordered collections, but there are no type-safe guarantees regardless of the orderliness of the sequence. It just happens that everybody writes things* in a way that preserves order coming from the iterator, because it's useful and expected.

Here's an example, where the parameter is totally disregarded, and the output's order is not deterministic. The language provides the freedom for this.

extension Collection {
  func 🗺️<🗺️>(_: 🗺️) -> [Element] {
    indices.shuffled().map { self[$0] }
  }
}

(1...5).🗺️("🫤")
(1...5).🗺️ { }
(1...5).🗺️ { $0 * 2 }

* Note: this breaks down for async sequences. The standard there is not to preserve order, unless the work is being done sequentially—parallelism requires more effort.