> 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.
This is exactly what `append` is for. If you're overwriting existing
entries (those between 0 and length), use `copy`. If you want to write new
entries (between length and capacity), use `append`.
On Wednesday, May 28, 2025 at 4:12:39 PM UTC-7 Keith Randall wrote:
> 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/138935d9-ad7c-4cbd-8749-6da07382b37bn%40googlegroups.com.
