Comment 1:

The issue is that if your code breaks out of the for loop
at line 83, then the goroutine created by the .Iter() is
still trying to send to the channel that you're ranging
over, but you've stopped reading it.  The workaround
for now is to use .Data() instead of .Iter()

Owner changed to r...@golang.org.

Status changed to LongTerm.

Comment 2:

Labels changed: added languagechange.

Comment 3 by Ziyu4Huang:

I think it's really a serous problem for my short example here:
package main
import "container/vector"
func main() {
  var v vector.Vector;
  for i:=0; i < 100; i++{
    v.Push(i);
  }
  for i:=0; i< 1000000; i++ {
    j:=0;
    for v:= range v.Iter() {
      if j > 3 { break}
      j++;
      _ = v;
    }
  }
}
If you don't fix earlier, I can image how much trouble it may cause.
It's very open that code may break before Iter() complete, if there is no way to 
automatically close, I suggest don't use it as iterator idiom.

Comment 4:

For your specific example, you should be ranging over
v.Data() anyway.  We don't have any data structures
yet that require the use of Iter. 
Whether channel iterator access turns out to be a
good idea for arbitrary data structures is yet to
be determined.  It obviously needs some work, but
it's not a top priority right now (garbage collector,
maybe generics, maybe exceptions, ...).
However, using channels for iteration isn't the only
reason to have range on channels.  The examples like
the prime sieve (or, a real example, the rpc package)
make good use of range over channels.

Comment 5:

Issue #1111 has been merged into this issue.

Comment 6:

I think goroutines are not going to be magically collected.

Status changed to WontFix.