cc @dsnet as I've seen him involved in similar threads like #55905 (comment). This issue could perhaps be a duplicate.

append could detect this, but it's not clear it is worth it. It would require a compare/branch on every append, but in the vast majority of cases it wouldn't trigger.

What is the situation in which this occurs in practice?

Yes, such cases are rare. I haven't encountered such case in my serious Go projects.

Maybe, it is good to keep the difference between copy and append here, so that people can choose the best way for different situations.

So does this mean append is a bit faster than copy (if append doesn't need to allocate) for most cases?

Thought it a little more. append will check capacity and copy will check addresses, which may make their performances on par for most no-allocations cases. This means copy is a better choice for no-allocations cases.

Please fell free to close this issue if nothing needs to be done.

It looks append will also check memory overlapping, just as copy.
This is proved by the following program:

package main

import (
	"fmt"
)

func main() {
	var x = []int{0, 1, 2, 3, 4}
	_ = append(x[1:], x[:len(x)-1]...)
	fmt.Println(x) // [0 1 2 3 4]
	               // not [0 0 0 0 0]
}

That means append(dest, src) will execute

   dest = dest[:len(src)]
   srcStart, srcEnd := &src[0], &src[0] + ElemSize * len(src)
   destStart, destEnd := &dest[0], &des[0] + ElemSize * len(src)
   if srcStart < destStart && srcEnd > destEnd {
      ... // need some special handling
   } else {
      ... // copy by normal order
   }

So, I think adding a srcStart == destStart check will not make a big impact on performance, even if for most cases it is needless.

Sorry, the proving example is corrected now.

Change https://go.dev/cl/533276 mentions this issue: slices: use copy instead of append in Delete

Change https://go.dev/cl/536255 mentions this issue: slices: avoid an unnecessary check in Replace