Sliced by Go’s Slices
4 points by ohrv
4 points by ohrv
I get it, but not doing this would require making a copy at every call site. I wish Go had had generics and iterators from the start, then it could just be an immutable view of the data.
Go’s slices could have been immutable without needing either of these.
Of course that would have required a separate vector type at least, but I think that bit of laziness (not having separate slice and vector types) does rank as one of the worst mistakes of the langage.
But would a separate type won’t be unusable without generics? Or at least much more capable interfaces?
You are right that the bigger issue is that there’s no easy way to express an immutable view here, but wouldn’t a small copy be worth it? A 3 pointer-size copy is not a high cost overall.
You’re assigning so a shallow copy (which is likely what is happening) does nothing to protect you since the buffer behind the pointer is what’s being updated.You could easily test that by append-ing instead.
The Python example has completely different semantics, Python copies the backing buffer (by creating a new tuple from whatever iterable you passed in).
Sorry got distracted midway so wrote random stuff -I mean that in this case a copy would be 3 ints, but of course that’s unbounded . Still, the …s implies pretty strongly that you might be copying the buffer (shallowly)
Slices in Go are a good example case of how simplicity at the wrong level of abstraction leads to more complexity.