Think of `copy` as a safe `memmove`. There's nothing more to it. It does
not modify the length or capacity of anything. (And it can't. `copy(a,b)`
cannot modify either the length or capacity of `a` or `b`. Slices, and
particularly the slice's length and capacity, are passed by value.)
```
func f(a []int) {
a = a[1:2:3] // set a's length to 1, capacity to 2
}
a := make([]int, 5, 10)
f(a)
// a's length is 5 and capacity is 10 here.
// f only modified its local variable. It did not modify its caller's local
variable.
```
This is why the results of `append` need to be assigned somewhere. The
complete statement `append(a, 9)` writes 9 to a[len(a)], but doesn't (and
can't) modify a. You have to use the statement `a = append(a, 9)` to get
a's length updated.
On Wednesday, May 28, 2025 at 2:16:54 PM UTC-7 Jason E. Aten wrote:
> 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/295d236d-588b-4da1-914f-a6b6bc6f06c5n%40googlegroups.com.
