Hi Сергей It sounds like you are coming from a C/low level optimization point of view. Which is great. But there are things about Go that might you surprise you then. For example, the backing array for the slice is always fully zero-value initialized anyway. So changing its length within its capacity doesn't do any _extra_ zero-ing, like you suggest. It was already done.
This question might also be learning-path dependent. When I learned Go, and still to this day, I rarely if ever think about capacity, just the length. I just allocate the length I want/need, and go from there. From that point of view, copy makes perfect sense. Really cap is an optimization for when you're mostly done and want to squeeze out the last 1% by staring at the profiler for a day. I suggest that you can, and perhaps should, just ignore cap when you are learning how Go works or is typically used. The only time I even think about capacity is when I'm passing a temporary workspace slice to a serialization or encryption function. This is a common pattern in the crypto libraries. You have a big re-usable slice, but you set its length to zero when passing it to the encryptor/serializer subroutine, leaving its capacity large. In turn, the subroutine can re-use that memory, communicating back how much it used by returning a slice pointing to the same backing array. Since encryption is typically 1-1 your program can be made to do additional allocation after the setup. Conversely, if the provided buffer was not big enough, the subroutine must allocate, and it will return the bigger workspace, which can still be re-used next time. BUT, the subroutine doesn't even really have to do anything to make this happen. Nice! What? How can that be? How this works: the subroutine just takes a slice as an input argument, appends blindly, and returns the slice in a return value. The slice will automagically get reallocated --but only if there wasn't enough space to handle all the appending. Hope this helps. You don't really have to think about cap until later in your journey, and it will all work just fine. Best wishes. Jason On Wednesday, May 28, 2025 at 5:41:58 PM UTC+1 Сергей Пилипенко wrote: > Hello, gophers! > > I have attempted to use the copy function for slices and found it’s API a > bit strange. Suppose I have two slices: one of size 0 and capacity 10, the > other of size 10 and capacity 10. When I copy the second one into the first > one nothing happens, because the length of the first size is 0, although it > could hold the elements just fine. > > So, I am wondering why isn’t copying limited by the capacity of the > destination slice instead? It doesn’t look natural for me to have to pad > the slice with the default values of the type, as they will be overwritten > by the copy anyway. > > Thank you for the time! > -- 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 visit https://groups.google.com/d/msgid/golang-nuts/3e91afac-47f4-4ada-9941-b03c067f7043n%40googlegroups.com.
