Motivation:
Appending a new element to a slice is probably the most common slice operation.
The semantics of the append operator might lead to unwanted bugs due to the return parameter.
Consider the following code:

anotherSlice := append(existingSlice, ...entries)

When assigning to a variable different from the source slice, anotherSlice might or might not end up pointing to the same array as in existingSlice.
Since append is such a common operation in Go, it's very easy to miss this nuance and run into a strange bug with some elements "disappearing" from the slice due to another slice holding a pointer to the same array. This issue is very hard to debug.
While there is a linter in gocritic that tackles the exact same problem, it'd be more efficient to exclude this problem on the language level

Solution:
We can improve the situation by introducing a new function for "just appending" to the slice

func Push[S ~[]E, E any](src *S, newElements ...E) {
	*src = append(*src, newElements...)
}

Then, you can use it like this:

Push(&existingSlice, entries)

This solution has the following benefits:

• With this API one cannot accidentally have two slices owning the same backing array(i.e. The user would have to explicitly declare a new slice, copy the content of existingSlice and only then append what they intended to)
• works for any slice including nil slices
• this doesn't break any backward compatibility since append is still available as an operator
• Slice grow is hidden from the developer. Hence, one does not need to think about resource ownership with this API