This is the kind of example I was hoping for, and I understand a little better now where collect() can have semantically-visible side effects. It seems like it should be possible to have a smarter type system that can tell the difference between futures where collect() can be optimized out and ones where they can't though.
> It seems like it should be possible to have a smarter type system that can tell the difference between futures
While that Java code is neat, you don't need to get anywhere near concurrency to exhibit problems with side effects. Here's a program with two iterator chains and two calls to collect:
let foo = [1, 2, 3];
let bar: Vec<_> = foo.iter()
.map(|x| {
print!("{} ", x);
x + 10
})
.collect();
let qux: Vec<_> = bar.iter()
.map(|x| {
print!("{} ", x);
x * 10
})
.collect();
This program prints "1 2 3 11 12 13 ".
Here's that same program, but with the first collect removed and the iterator chains collapsed into one:
let foo = [1, 2, 3];
let bar: Vec<_> = foo.iter()
.map(|x| {
print!("{} ", x);
x + 10
})
.map(|x| {
print!("{} ", x);
x * 10
})
.collect();
This program prints "1 11 2 12 3 13 ".
When you have two iterator chains with two calls to collect, everything in the first iterator runs to completion, then the second iterator chain runs. When you collapse those two chains into one, you change the order in which things happen.
It's still true that a smarter type system would be able to track side effects, but like all effects systems, these things are viral, and it's not immediately clear whether the annotation burden makes up for itself in optimization potential.
