Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

a[low:high:max] in Golang – A Rare Slice Trick

build-your-own.org

Post reply on HN
Print view View original

21–30 of 131 posts

Re: a[low:high:max] in Golang – A Rare Slice Trick

#21

Post by Groxx »

DougBTX wrote: post #20
Groxx wrote: post #6

Earlier quoted context omitted.

Append mutates or copies-and-appends based on the capacity of the slice it's given. And since slicing an array or a slice gives you just a view , not a copy, it can cause "spooky action at a distance" and mutate things you didn't expect, especially if it was a slice with extra capacity of data used somewhere else. Which is what this article is describing. Plus the knowledge of the change in length (to see the appende…

So in other words, appending to a slice may overwrite data in the middle of a different slice?

Yep. Depending on how the slice was constructed, not how it is used.

Slices (largely) behave like this in most languages, Go's contribution is mostly that slices and append are ubiquitous, so pretty much every Go coder is exposed to it. Prior to generics, literally any alternative was so much more work they essentially haven't been used. That may change in the future now that we do have (very simplistic) generics, but only time will tell.

Re: a[low:high:max] in Golang – A Rare Slice Trick

#22

Post by ikiris »

Groxx wrote: post #13
wyager wrote: post #11

Earlier quoted context omitted.

This is a pretty good vignette of how Go is designed. "Users don't need this feature (immutability, polymorphism, etc.), let's not include it. Ah crap, turns out we actually need it for a core language feature. Is there a lesson we can take away here? Nah, just make an ad-hoc implementation of the functionality in this one place."

"X for me but not for thee" is very much the vibe Go gives me, yeah. I mean, I have completely replaced my adhoc Python use with it and I'm much happier. But it's terrifying to use to build large systems.

Part of it is that "large systems" are almost all combinations of small systems with proto boundaries, so it's not much of an actual risk unless you're making giant monolith code.

Re: a[low:high:max] in Golang – A Rare Slice Trick

#23

Post by mook »

Izkata wrote: post #18
gleenn wrote: post #3

Earlier quoted context omitted.

I don't know much Go but what does it mean to "accidentally" append to an immutable array? Are there just no particular guards for arrays and they are saying something which should be treated as immutable?

Sounds like they're just badly describing copy-on-write. The original slice uses no extra memory because as long as you treat it as immutable it won't actually make a copy. As soon as you try to modify it, then the copy is made and the extra memory used.

Yes-ish; because go has no immutable slices, it's just copy-on-realloc. Which is if course obvious if realize that's what it's actually doing…

Re: a[low:high:max] in Golang – A Rare Slice Trick

#24

Post by pstuart »

TwentyPosts wrote: post #8
gleenn wrote: post #3

Earlier quoted context omitted.

I don't know much Go but what does it mean to "accidentally" append to an immutable array? Are there just no particular guards for arrays and they are saying something which should be treated as immutable?

Go has no way to ensure "const correctness". If you pass around a slice (which you'll be doing a lot, since it's essentially Go's equivalent of a vector), everyone can modify the slice however they please. It's just a fat pointer. So yes, something which should be treated as immutable. The way Go works here easily leads to bugs, especially when concurrency is involved and slices get captured or used by goroutines. If…

On the bright side, if one tests with race detection enabled these problems are usually made apparent.

Re: a[low:high:max] in Golang – A Rare Slice Trick

#27

Post by morelisp »

Groxx wrote: post #9
TwentyPosts wrote: post #8

Earlier quoted context omitted.

Go has no way to ensure "const correctness". If you pass around a slice (which you'll be doing a lot, since it's essentially Go's equivalent of a vector), everyone can modify the slice however they please. It's just a fat pointer. So yes, something which should be treated as immutable. The way Go works here easily leads to bugs, especially when concurrency is involved and slices get captured or used by goroutines. If…

But also strings are actually immutable sometimes (at the very least when hardcoded), and they can be converted to a `[]byte` slice that looks mutable, but panics when modified. AFAIK no other slice-like data in Go behaves like this. Fun!

This is misleading enough it's a lie; to do this you need to use a function named `unsafe.Pointer` with a type named `reflect.StringHeader`, not just `[]byte` and `string`.

Re: a[low:high:max] in Golang – A Rare Slice Trick

#28

Post by morelisp »

nutate wrote: post #26

My fave golang slice trick is the len of an empty slice is 0, but the slice itself is == to nil, but the len of nil won't compile. Can't understand that one. https://go.dev/play/p/MslCkBphl7q?v=gotip

Because the bare value `nil` has no type. Typing it, e.g. `len([]int(nil))` works fine.

Re: a[low:high:max] in Golang – A Rare Slice Trick

#29

Post by sacnoradhq »

0. Only 2 of 3 values are necessary.

1. Can 1 value be unspecified?

2. Can 2 values be unspecified?

3. Can 3 values be unspecified?

4. Are conflicting values interpreted as intersection of ranges rather than union?

Note 1-3. With 2 values, I believe x[:] is how to lift a sized array into a more generic slice type.

Re: a[low:high:max] in Golang – A Rare Slice Trick

#30

Post by iainmerrick »

Groxx wrote: post #21
DougBTX wrote: post #20

Earlier quoted context omitted.

So in other words, appending to a slice may overwrite data in the middle of a different slice?

Yep. Depending on how the slice was constructed , not how it is used. Slices (largely) behave like this in most languages, Go's contribution is mostly that slices and append are ubiquitous, so pretty much every Go coder is exposed to it. Prior to generics, literally any alternative was so much more work they essentially haven't been used. That may change in the future now that we do have (very simplistic) generics, b…

Slices (largely) behave like this in most languages

Is that really the case? I can’t think of many languages that let you construct a view into the middle of array, pass that view as an argument to a function call, and allow that function to add new values into your array via the view.

In Python or JS, for example, the “slice” would just be a brand new array, right?

Post reply on HN