slices: grow should document zeroness of extended elements

[dsnet]

In the event that Grow grows a slice, what assumptions are we allowed to make about the zeroness of the added elements? The current implementation guarantees that they are zero. Can we document that fact?

I have a loop that looks something like:

var s []T = ...   // possibly a pooled slice
mustZero  := true // we do not know the cleanliness of unused capacity
for hasMore() {
    if len(s) == cap(s) {
        s = slices.Grow(s, 1)
        mustZero = false // TODO: Is it safe to assume extended elements are zero?
    }
    s = s[:len(s)+1]
    e := &s[len(s)-1]
    if mustZero {
        *e = T{} // T may be large, so we want to avoid doing this if possible
    }
    mergeInto(e)
}

As an optimization it relies on slices.Grow extended the slice with zero elements, but this is not a documented guarantee.

\cc @ianlancetaylor

[ianlancetaylor]

My first thought is that we shouldn't assume that Grow will zero out elements between the length and the capacity. In particular, if the capacity is already large enough, I can easily imagine a version of Grow that would leave the slice untouched.

[dsnet]

I think it's fine to leave the behavior of new[len(old):cap(old)] to be undefined.

The issue is about guaranteeing that new[cap(old):cap(new)] will always be zero initialized. I can't imagine any situation where this wouldn't be zeroed since any newly allocated slice from the runtime (either through make or append) should return zero initialized elements.

[ianlancetaylor]

OK, sure.