Actually, this example is a bit unfortunate. Depending on the implementation of append, the capacity of s3 may be small enough that a new buffer must be allocated for s4, which means there is no need to test for overlaps. https://go.dev/play/p/n5FNqlA0DaS demonstrates that this is what happens in the current implementation, and also (x3 and x4) shows that overlaps are handled correctly when the existing buffer has enough capacity to be reused.
On Wed, Aug 2, 2023 at 9:49 PM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > You're not missing anything. The example is correct and helpful. It's also > something that can be tested out, for definite confirmation > <https://go.dev/play/p/KedJPb2xPYv>. > >> >> On Wednesday, 2 August 2023 at 17:59:06 UTC+1 Kamil Ziemian wrote: >> >>> Second, I have question about example shown in section "Appending to and >>> copying slices". >>> >>> s0 := []int{0, 0} >>> s1 := append(s0, 2) // append a single element s1 == >>> []int{0, 0, 2} >>> s2 := append(s1, 3, 5, 7) // append multiple elements s2 == >>> []int{0, 0, 2, 3, 5, 7} >>> s3 := append(s2, s0...) // append a slice s3 == >>> []int{0, 0, 2, 3, 5, 7, 0, 0} >>> s4 := append(s3[3:6], s3[2:]...) // append overlapping slice s4 == >>> []int{3, 5, 7, 2, 3, 5, 7, 0, 0} >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAADvV_st8xDE16ndVOCqqmwZLS1pN5U17ECM_mwjs%3DbGe61w8A%40mail.gmail.com.
