Comment 1:

It should probably be
for i := range b {
   b[i] = 0
}
and let the compiler optimize it.

Comment 2:

Ideally, yes.
Rob was talking about this, so I filed a bug.
I'd also want:
for i := range b {
   b[i] = MyStruct{}
}
... to be recognized.

Comment 3:

Yes, it should work for any zero value.

Comment 4:

I'd hope for
for i := range b {
   b[i] = 42
}
to be optimized in the same way.

Comment 5:

Labels changed: added go1.2maybe.

Comment 6:

Labels changed: added go1.3, removed go1.2maybe.

Comment 7:

Labels changed: removed go1.3.

Comment 8:

Labels changed: added go1.3maybe.

Comment 9:

Had to implement an object pool. Needed this.

Comment 10:

Labels changed: added release-none, removed go1.3maybe.

Comment 11:

Labels changed: added repo-main.

Comment 12 by lk4d4math:

snappy-go now suffer from huge hashtable allocations on each encode. Now bultin
copy(dst, initSlice) works twice faster than loop, but it is still slow like new
allocation.

Comment 13:

In Go 1.2 we picked up 20-30% for snappy. Can you please provide some more details about
the issue you are seeing.

Comment 14 by lk4d4math:

I am just test some snappy libs and python(just wrapper for C++ implementation) is twice
faster than pure go implementation. I used profiler and see that significant time
spending on allocating empty array of 1<<14 size. So I am tried write memory pool
and request "golang memset" led me here)

Comment 15 by lobais:

Really, a way to zero any type, would be ideal.
If 
    for i := range b {
        b[i] = MyStruct{}
    }
were recognized as a way to zero a slice of `MyStruct`, then
    s := MyStruct{...}
    s = MyStruct{}
should probably also do no allocations (in line 2).
But then, for a struct like
    type MyStruct struct {
        slice []int
    }
there would suddenly be a no-loop way to zero an int-slice.
I don't know what to make of this, other than that zeroing types seems like a natural
thing to do, given Go's great idiom of zeroed types being (transitively) useful.

Comment 16:

memclr only: https://golang.org/cl/137880043
memset requires an efficient runtime memset implementation and a discussion of pattern
length: repeating bytes? repeating words?
As a data point, a pass through the stdlib yields three non-test uses of this memset
idiom:
strings/replace.go NewReplacer
strconv/decimal.go digitZero
httputil/dump.go neverending.Read
All are slices or arrays of bytes.

Owner changed to @josharian.

Status changed to Started.

I consider this fixed. Optimizing non-zero cases isn't very interesting.

We can open another bug if people feel strongly about doing more.