slices are not complicated, the issue is append, mutable slices and backing arrays being shared, that's what's really fucky about it.
And that interaction is absolutely a WAT. Especially the ability to separately append to two slices with the same backing array.
> A lot of WATs are more bad practice than problems in the language, IMO
Much the same could be said about the original presentation.
There absolutely are non-WAT sections in that article though. (4) is one.
I'm not sure views into a fixed-sized array is really confusing/strange at all. Whether you create multiple views in the array, mutate the views, etc. All interactions that occur on slices and arrays make plenty of sense. How you'd write something like append yourself if "Slice" was your type w/ a backing array, a start index, and a length is quite straightforward.
In a language that encourages concurrency, this indeterminism should be jaw-dropping. How many Go programs are safe only accidentally via an array's allocation policy (especially given how much code it requires to duplicate a slice)? Can you think of any other language that has such a design?
> Can you think of any other language that has such a design?
Sure, happens all the time because it fits the machine naturally though sometimes it may be hidden with unnecessary runtime costs by many languages that do force copies or reallocations due to immutability. C++ is a language that doesn't hide it. Your argument is like saying you're surprised that std::vector::emplace_back may or may not alter the array I had kept from std::vector::data previously.
Again, as I already stated in the previous comment the issue is not the slices themselves.
It's that they're doubling up as vectors and they're shitty at it: you can share a backing buffer between mutable slices and append to both and then all hell breaks loose.
That is the issue. And that is why Rust doesn't have that issue despite having the same concept of slices: you can't grow a slice, and you can't have multiple mutable slices to the same backing buffer.
No. C only has raw pointers so it's not trying to pretend slices are vectors, and C++ has actual functioning vectors with "slicing" being either a copy of the subvector or an iterator. Either way there is no confusion as to the capabilities of what you're given and its relation to the original data.
Whether there are multiple views or not is actually an implementation detail, and whether "append" chooses to allocate memory or not will change whether there are multiple copies or multiple views of the array.
All of that behavior is something you absolutely cannot rely on.
Isn't that the tired old argument from the C camp? "If you are careful you can write perfectly fine C without bugs".
DUH!
The whole idea is for the compiler and types to catch as much of this crap as possible, not to add accidental mental burden to the programmer.
Is it though? Slices seem to be passed by value, where the value is a pointer and some bookkeeping information (like a C struct of (data, len, capacity)).
Some operations manipulate just data (which is visible in the caller, since that 1/3 of the "struct" was a pointer passed by value) and some operations manipulate len and/or capacity (which is not visible in the caller, since that 2/3 of the "struct" was also passed by value).
Seems more complex than just hand-waving the details away with "pass-by-reference 101".
So, probably more like pass-by-reference-and-by-value 201.
Even if you pass a pointer, the pointer is explicitly copied to a new location in memory, which is why assignment to the pointer can overwrite the pointer, but not affect the original pointer (the memory location value inside the pointer-typed variable) outside the function scope.
Pass by reference is when assignment to a parameter name is transitive to the caller's scope, and can be seen in C#. [1]
[1] https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
Now in WAT 1,
func grow(s []int) { // s is deep copied.
s = append(s, 4, 5, 6) // changing 's' does not effect original slice.
}
func grow(s *[]int) { // s is referenced.
*s = append(*s, 4, 5, 6) // changing 's' will always effect origin slice.
}
type thing struct {
foo int
}
func f(x thing) {
x.foo = 42
}
func main() {
var x thing
x.foo = 1234
fmt.Printf("x before: %v\n", x)
f(x)
fmt.Printf("x after: %v\n", x)
}
func f(x []int) {
x[1] = 42
}
func main() {
x := []int{1, 2, 3}
fmt.Printf("x before: %v\n", x)
f(x)
fmt.Printf("x after: %v\n", x)
}
As you write more go, you will begin to fully see the existence of a backing array. Try this program:
func main() {
x := []int{1,2,3,4}
y := x[1:2]
y[0] = 42
fmt.Printf("x: %v, y: %v\n", x, y)
}
Now, add some knowledge from the documentation about how append() works. You use the idiom slice = append(slice, element) because the documentation says, sometimes the slice is updated in place when there is enough capacity for that to occur, and sometimes the slice is copied to a new slice and returned.
This then leads to your "WAT" in WAT 2. Because you _know_ that the data you appended is actually in the backing array, but for some reason Go isn't showing it to you.
You can see this in action with a very poor example I just wrote:
func main() {
x := []int{1, 2, 3, 4, 5, 6}
y := x[0:0]
fmt.Printf("x: %v, y: %v\n", x, y)
fmt.Printf("intermediate result that's not saved: %v\n", append(y, 9, 8, 7, 6, 5))
fmt.Printf("x: %v, y: %v\n", x, y)
}
For that reason, I think WAT 2 is worthwhile. Most people know _just enough_ about slices to be dangerous, and so are surprised when there is an additional complication that they haven't thought about.
Until it doesn't.
type thing struct {
foo *int
}
func f(x thing) {
*x.foo = 42
}
func main() {
v := 1234
var x thing
x.foo = &v
fmt.Printf("x.foo before: %v\n", *x.foo)
f(x)
fmt.Printf("x.foo after: %v\n", *x.foo)
}
A lot of WATs are more bad practice than problems in the language, IMO (like WAT 8, modifying the return value twice in deferred functions, with the order being significant: who the hell writes such a code?)
A few ones, though, really are problematic. For instance I've been bitten more than once by variable shadowing, especially with error values. IMO, this is the weakest point of Go.