It's a little bit surprising that using a fold rather than a simple loop has such a high overhead. I was already pretty sure of the result, but I went ahead and

It's a little bit surprising that using a fold rather than a simple loop has such a high overhead. I was already pretty sure of the result, but I went ahead and wrote a quick benchmark in Rust, and there is no overhead to using a fold rather than a loop (each iteration is addition of a million values of the stated numeric type): test tests::bench_fold_f64 ... bench: 984,829 ns/iter (+/- 30,827) test tests::bench_fold_i32 ... bench: 84,497 ns/iter (+/- 16,109) test tests::bench_loop_f64 ... bench: 993,406 ns/iter (+/- 45,791) test tests::bench_loop_i32 ... bench: 81,306 ns/iter (+/- 17,815) That this isn't true in Swift is way more interesting to me than the fact that overflow checking has overhead (duh). It's not difficult to come up with some theories as to why this might be the case, but still, if using these "functional" constructs in Swift has such a high overhead, programmers should probably be questioning whether it's worth using them at all. edit: I see that I've been beaten to the punch posting a Rust benchmark :)