undefined | Better HN

0 pointssaghm2y ago0 comments

Okay, yeah, that definitely isn't what I expected. It's pretty wild to me that `s = s[:2]` will ever work fine if `len(s) == 1`; I would have assumed that it would always be the same regardless of how the slice was created. Playing around with it, it seems like this means that if you pass a subslice to a function, that function can get access to things from the entire slice, including the portions that weren't in the slice passed in[1]!

I think I understand now why `clear` can't work on slices the way I think it should, but only because slices themselves don't work the way I feel even stronger that they should.

[1]: https://play.golang.com/p/fYrGUbCePuD

0 comments

arp2422y ago

Slices in Go are a tad counter-intuitive, I agree, but the approach does make sense I think. It allows you to use "dynamic sized arrays" for most cases like you would in Python and not worry too much about the mechanics, at the price of some reduced performance, but in cases where this kind of performance does matter it allows you to be precise about allocations and array sizes. So you kind of get the best of both.

Anyhow, this explains it in detail, if you're not already familiar with it: https://go.dev/blog/slices-intro

j / k navigate · click thread line to collapse

0 pointssaghm2y ago0 comments

I think I understand now why `clear` can't work on slices the way I think it should, but only because slices themselves don't work the way I feel even stronger that they should.

[1]: https://play.golang.com/p/fYrGUbCePuD

0 comments

arp2422y ago

Anyhow, this explains it in detail, if you're not already familiar with it: https://go.dev/blog/slices-intro

j / k navigate · click thread line to collapse