Cut from the slice of pointers. Memory leak

Getting Help
1 
a = append(a[:i], a[j:]...)

Go Wiki: SliceTricks - The Go Programming Language states:

NOTE If the type of the element is a pointer or a struct with pointer fields, which need to be garbage collected, the above implementations of Cut and Delete have a potential memory leak problem: some elements with values are still referenced by slice a’s underlying array, just not “visible” in the slice. Because the “deleted” value is referenced in the underlying array, the deleted value is still “reachable” during GC, even though the value cannot be referenced by your code. If the underlying array is long-lived, this represents a leak. The following code can fix this problem:

Cut

copy(a[i:], a[j:])
for k, n := len(a)-j+i, len(a); k < n; k++ {
    a[k] = nil // or the zero value of T
}
a = a[:len(a)-j+i]

Am I correct in understanding that the last j-i pointers of the original slice will not be visible in the resulting slice, but will remain in memory to provide capacity to the resulting slice. The last j-i pointers of the original slice are the same as the last j-i pointers of the resulting slice. The problem here arises if we replace the last j-i pointers of the resulting slice. Not considering that copies of them remain in the capacity, we can hope that the objects pointed to by the old pointers will be garbage collected, but this will not happen (since these elements remain in the capacity of the resulting slice)
?

2

I’m not sure what your specific question is?
For slices, the usual access restriction is only [0, len), but the actual length of the underlying storage array is cap, which is the usual implementation of mutable containers.
If you have tried to write an algorithm implementation in C or C++ (similar to that), you won’t be confused.

3

My question is how to understand the note from Go Wiki: SliceTricks - The Go Programming Language ( NOTE If the type of the element is a pointer…).

4

If you think of slices as:

type slice[T any] struct {
    arr *[cap]T
    len int
    cap int
}

it explains a lot.

6

Yes, you are right. It can be a potential memory leak in case if you are not zero-ing values of pointers. For example you can check out new slices package and it’s Delete function. If you check out the history of modifications, in version 1.21, when it was added, it has notation that it might not gc-ed pointers. But starting with 1.22, it uses clear to allow GC to free data even if it represented by pointers.