Comment by masklinn
1 year ago
> once we remember that a slice is a view into an array and that "some" of these methods return slices, it's actually fine.
Only in the meme sense, it does not actually solve or help solve the problem in any way.
1 year ago
> once we remember that a slice is a view into an array and that "some" of these methods return slices, it's actually fine.
Only in the meme sense, it does not actually solve or help solve the problem in any way.
If the problem is that slices are somewhat complex, allowing aliasing sure.
But then it's a problem of understanding what slices are so it does help in practice.
I am more concerned by the difficulty of mutating a slice (deleting and appending element) while iterating over it for instance. Done it and that's more difficult, ceremonious.
> If the problem is that slices are somewhat complex, allowing aliasing sure.
No, the problem is what I put at the top, that slices are hopelessly confused, they have two completely different and incompatible purposes and Go does not let you differentiate between the two.
Understanding what slices are does not help, neither in theory nor in practice.
The way I see it, this is just lower level for mechanical sympathy and one is still free to implement a copy-on-write wrapper. Been there, done that.
The trick in understanding what they are is to understand that these are not vectors if I try to get closer to your semantics. Once it is viewed purely as a kind of reference type, a view in a backing array, it has only one meaning.
It's easier for a traditional functional language to implement lists and vectors perhaps because they operate on the premise of immutability first. Beware of the memory footprint though.
I admit that it might be easier to think in term of vectors. That's kind of what was done designing the wrapper.
Still, as I understand, slices are just lower-level. Immutability is a higher, language level concept.