The current runtime function for this takes into account element size, so you'd have to pass that in as well.

You could have an init function that calculates these values for you by appending an element at a time and seeing what happens. Something like below:

package main

func main() {
	var a []byte
	for i := 0; i < 40; i++ {
		a = append(a, 3)
		a = a[:cap(a)]
		println(cap(a))
	}
}

The current runtime function for this takes into account element size, so you'd have to pass that in as well.

Ok, that shouldn't be an issue to add element size parameter:

func AppendNewCap(currCap int, newElemCnt int, elemSize uintptr) int

The expected usage could be something as:

newCap := AppendNewCap(len(curr), len(curr) + len(toAppend), unsafe.Sizeof(myStruct))

I hope it would not be an issue that an unsafe function would be required to call a runtime function, would it?

You could have an init function that calculates these values for you by appending an element at a time and seeing what happens. Something like below:

I thought of this and unfortunately this doesn't seem to be possible.

First of all, such a function measuring capacity growth of a specific slice wouldn't be optimized by the compiler to no-op. Consequently, the program would really have to allocate such an slice every time it runs. Which could have non-trivial performance impact especially in cases of bigger arrays.

But even when we ignore the performance impact of your proposal, you would still have to set some maximum of the measurement: Let's for example say that in the current implementation, the new capacity of a slice after append has a deterministic formula once slice capacity exceeds 1024. Consequently, based on current implementation of append, we measure capacities of our test slice up to 1024 and find out what the capacity growth should be. For capacities above 1024, we just use the well-defined formula. But if the way how capacity above 1024 elements (or even the 1024 elements boundary) changes in future versions of Go, our code will no longer be consistent with the new behaviour of append. To sum it up, there is no real upper bound where the measurement proposed by you should end.

Based on this observation I believe that the only way how to maky any such custom append algorithm forward compatible (read consistent with even future behaviour of append) is to expose this calculation function from the runtime package.

FWIW, in my deque package, I use append specifically to get the cap behavior of append. The same also occurred when I wrote a slice.Grow-like function for []byte. If a function like this existed, it would be simpler to just call runtime.AppendNewCap instead.