Looks like the difference is that the faster code is able to elide zeroing the allocation.

I dont think its clear cut we should do this. I would rather prefer that programmers wanting the increased performance write make+copy directly. Otherwise we will go down a path of adding more and more complexity rewriting append patterns in the compiler that are more idiomatic in my opinion to be written as e.g. make+copy in the first place.

Otherwise we will go down a path of adding more and more complexity rewriting append patterns in the compiler that are more idiomatic in my opinion to be written as e.g. make+copy in the first place.

FWIW, I don't think make+copy is particularly idiomatic either — I don't think this sort of pattern occurs frequently enough to have a clear “idiom”.

I will, however, point out that except for the string special-cases, copy can be defined in terms of append (https://go2goplay.golang.org/p/nfU-IUC7l7k):

func copy[S SliceOf[T], T any](dst, src S) int {
	n := len(src)
	if n > len(dst) {
		n = len(dst)
	}
	_ = append(dst[:0], src[:n]...)
	return n
}

In contrast, append cannot be defined in terms of copy, because it has additional allocation behavior that copy lacks — and the allocation behavior is explicitly what the user is concerned with in the examples here.

So it seems to me much more natural for users to reach for append whenever allocation is involved, and copy only when the function doesn't need to allocate in the same step.

At any rate, given that copy can be defined in terms of append, and given that append avoids unnecessary zeroing in many other cases, I think it's strange for a pattern involving append to redundantly zero out data when copy does not.

and the allocation behavior is explicitly what the user is concerned with in the examples here.

But the allocation in the example here is explicitly not done by append but by the make. The append here is used only for the copy part.

The suggestion here is not to rewrite append to make+copy but to rewrite make+append to make+copy. The append here is used to allow to write it as one expression returning a copy.

Once generics are around a slices.Clone function might ideally take care of a more concise expression to clone a slice in one expression.

Another way to write a slice clone is append([]T{}, s...)[:len(s):len(s)] which I think would also need to be considered to be performance optimized similar to make+append.

It would be great if the same optimization also works for the following two make calls.

func InsertVerbose(s []int, k int, vs ...int) []int {
	if n := len(s) + len(vs); n <= cap(s) {
		s2 := s[:n]
		copy(s2[k+len(vs):], s[k:])
		copy(s2[k:], vs)
		return s2
	}
	s2 := make([]int, len(s) + len(vs))
	copy(s2, s[:k])
	copy(s2[k:], vs)
	copy(s2[k+len(vs):], s[k:])
	return s2
}


func InsertVerbose_b(s []int, k int, vs ...int) []int {
	if n := len(s) + len(vs); n <= cap(s) {
		s2 := s[:n]
		copy(s2[k+len(vs):], s[k:])
		copy(s2[k:], vs)
		return s2
	}
	s2 := make([]int, 0, len(s) + len(vs))
	s2 = append(s2, s[:k]...)
	s2 = append(s2, vs...)
	s2 = append(s2, s[k:]...)
	return s2
}

[update]:

func MergeSlices(data ...[]int) []int {
	n := 0
	for _, s := range data {
		n += len(s)
	}
	r := make([]int, 0, n)
	for _, s := range data {
		r = append(r, s...)
	}
	return r
}

Not sure whether or not the following make call reset elements:

  s := make([]byte, len(aString) + len(aByteSlice))
  copy(s, aString)
  copy(s[len(aString):], aByteSlice)

[update] After some investigations, if looks the element in s[:len(aString)] are not reset to zero, but others are reset.