You can, in fact, reduce the capacity. Example: https://go.dev/play/p/4SH0lRFFUXt
The "full form" for slices is not a frequently used feature though. https://go.dev/ref/spec#Slice_expressions This can also be used to reslic a slice to access the data between the length and capacity. On Wed, May 28, 2025, 20:20 'Alexander Ertli' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Hi, > > I think the core reasoning is that once a slice is created, its capacity > is fixed – you can’t really change it without allocating a new backing > array and copying elements over. You *can* reduce the length easily (s = > s[:n]), but not the capacity. > > ```a := make([]int, 0, 10) > b := make([]int, 10) > copy(a, b) // nothing happens – a's len is 0 > > a = a[:10] // extend length to allow copy > copy(a, b)``` > > Sometimes in low-level or performance-critical code, a slice is reused as a > shared buffer across function calls to avoid allocating every time. You just > reset the length as needed: > > ``` > buf := make([]byte, 0, 4096) > // reuse buffer > buf = buf[:0] // zero-length, same capacity > ``` > > > So len becomes the contract for how much is valid at any moment, and cap just > tells how many elements you in theory could add, if len is adjusted. > Apart from the shared buffer case, there are probably other use cases for > this, but that's the one that comes to mind. > > Maybe someone else has another reason why it’s designed this way? > > I hope this still helps. > > > > > Am Mi., 28. Mai 2025 um 18:41 Uhr schrieb Сергей Пилипенко < > territhi...@gmail.com>: > >> 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/0447e9ef-2daa-4fe5-b1b6-b05a5caeafeb%40Spark >> <https://groups.google.com/d/msgid/golang-nuts/0447e9ef-2daa-4fe5-b1b6-b05a5caeafeb%40Spark?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAC4E5ZkwRXK-kspT2S53vxrD%2Bhy6uJKKs7h_wV3Pu809KXnjSw%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CAC4E5ZkwRXK-kspT2S53vxrD%2Bhy6uJKKs7h_wV3Pu809KXnjSw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CADgY6e-KavRqv0SyEd%2BGT%3DonZyxjV4r2MpnLx1DWMsCHB4G_XQ%40mail.gmail.com.
