Array and Slice behaviors with len() and cap()

[Oluwatobi_Giwa]

Hey Good Gophers…
I’m just a 5 days newbie at Golang (3rd year as pythonista).

I was at this weird behavior (as I consider it) of array and slices, related to len() and cap() (especially cap()), the different use and behavior of [ : ] and [ : : ].

Just asking…, is this supposed to be a good thing I’ll later come to appreciate or …despise ?

Thanks.
Good to be here.

[skillian (Sean Killian)]

Hi, Oluwatobi, and welcome to the forum!

@Oluwatobi_Giwa

I was at this weird behavior (as I consider it) of array and slices, related to len() and cap() (especially cap()), the different use and behavior of [ : ] and [ : : ].

It would be helpful if you could describe what the weird behavior is! Do you have any example code where you could demonstrate what you expected vs. what actually happened?

[Oluwatobi_Giwa]

Thanks for the response. I’ve gotten the whole idea around it. It just feels weird, what am asking is if the community is actually ok with it or something everyone wants to actually change too?.

I feel like the behavior of [ : : ] on a slice should be the default. Just saying, i just don’t feel safe with it. Hopefully, i get used to it without scars .

[skillian (Sean Killian)]

I’m still not sure what it is about slices that feels weird to you, but while they’re different from, e.g., lists in Python or List<T> in C#, etc., they seem intuitive to me, but I’ve been using them for years .

[mje (Jeff Emanuel)]

@Oluwatobi_Giwa

something everyone wants to actually change

That’s extremely unlikely since this (the 3-index slicing) has been in Go for nearly 10 years. If everyone wanted it changed, then either the language would have changed (requiring a v2) or it would have died long ago. You still haven’t clarified what you don’t like. If modifying the capacity were the default, then there would be much more memory allocation churn, copying, and GC. FWIW, in my eight years of coding primarily in Go, I have almost never used the 3-index slicing. Almost all my operations that would change the capacity use append. Usually I specify the necessary capacity in make.

[Oluwatobi_Giwa]

Ok, the weird thing is this.

var arrOne [4]int = make([4]int, 4) // i.e len() is 4 and cap() is 4 int{0,0,0,0}

arrTwo := arrOne[:2]. // int{0,0}

arrThree := arrTwo[:3] // int{0,0,0}

The value of the arrThird is weird… buh i get it all know, the pointer and cap() stuff.

Guess, I’ll just have to get used to it.

[Oluwatobi_Giwa]

10 years…

I just picked up Golang 5 days ago… the backend python job market is getting too tight. I see Golang taking the future in the server-side space. Hence, why am here.

I’ve gone past the data structures, interfaces, Goroutines, Channels… currently at the Testing… using a book by O’reilly Learning Go, an idiomatic approach.

Please, any advice on how to take this new leap?, for Backend positions in Golang and other Golang opportunities in general.

Thanks

[mje (Jeff Emanuel)]

@Oluwatobi_Giwa

var arrOne [4]int = make([4]int, 4)

Invalid use of make.

./prog.go:8:22: invalid argument: cannot make [4]int; type must be slice, map, or channel

Instead, var arrOne [4]int gives an array of length 4.

@Oluwatobi_Giwa

arrTwo := arrOne[:2]. // int{0,0}

arrThree := arrTwo[:3] // int{0,0,0}

These are not arrays, so you shouldn’t name them as such. Go arrays have a size fixed at compile time. Passing an array copies the entire array. Go slices are view of arrays, so thinking of them that way helps to fully understand them. They also happen to be cheap to pass because copying them does not copy the element data. You get a new view of the same backing array.