if((((rx + rw +1 ) < x) || ((rx > (x+w +1 ))))) { RoomOkay=true } else if((((ry + rh +1 ) < y) || ((ry > (y+h +1 ))))) {RoomOkay=true }else {RoomOkay=fa

if((((rx + rw +1 ) < x) || ((rx > (x+w +1 ))))) { RoomOkay=true } else if((((ry + rh +1 ) < y) || ((ry > (y+h +1 ))))) {RoomOkay=true }else {RoomOkay=false} if(RoomOkay==false){ return true} Gaaaah, really? "go fmt" is your friend! That mess automatically cleans up into this: if ((rx + rw + 1) < x) || (rx > (x + w + 1)) { RoomOkay = true } else if ((ry + rh + 1) < y) || (ry > (y + h + 1)) { RoomOkay = true } else { RoomOkay = false } if RoomOkay == false { return true } > Particularly ugly is (*mySlice)[indexI].myField=newValue; > I’m not sure why the language can’t automatically dereference the slice when the [] operator is applied to it I don't know exactly what the Go team would have to say about this, but my take would be language simplicity. Pointers are pointers, and special-casing some of them breaks the rules that both the compiler and the programmer rely on. It may look like C, but it isn't. There's no pointer/array equivalence here, indexing and dereferencing aren't the same thing. If I weren't coming from a C background (which I'm guessing the author is, too), I'm not sure it would ever occur to me to expect a pointer-to-slice/array to be something you could index. Also, as a slice is basically a pointer to array plus two ints, you normally wouldn't pass a pointer to it in the first place. You only need to do that if you want to resize it.