3 ms·
my feeling with slices is that go wanted to really make programmers mindful of the cost of allocating new space on array operations. By having this weird API o
by bsaul 3y ago
my feeling with slices is that go wanted to really make programmers mindful of the cost of allocating new space on array operations.
By having this weird API on slices, they force you to be explicit on allocating new memory.
- masklinn 3y agoNone of that makes any sense. Slices don't force you to be explicit on allocating new memory in any way. you can literally do this: s := []int{} for i := range 29754 { s = append(s, i) } do you see explicit allocation of new memory? As far as I'm concerned that's not in any way more explicit than e.g. var s = new List(); foreach(var i in Enumerable.Range(0, 29754)) { s.Add(i); }
- bsaul 3y agos = append(s,i) makes you realize something happened to the memory behind s. Otherwise you would simply call s.append(i)
- masklinn 3y agoThe something that happens is that slices are not heap collections (unlike hashmap which say even less about allocations, but I'm sure you'll find an other excuse), so you can't even increment their length without returning a new copy. I also fail to see how this would translate to > make programmers mindful of the cost of allocating new space on array operations. anyway. `append` is not taking in an allocator, reporting allocation failures, or reporting reallocations here. Like proper vectors, it's silently reallocating (and over-allocating) as needed.
- deleted 3y ago[deleted]
- shakow 3y ago> they force you to be explicit on allocating new memory. Not at all. With e.g. `append` being a “maybe I'll allocate, maybe not, take a guess” kind of method, it's basically just like Java's `List.add` with extra steps and much worse egonomics.