Hacker News Reader

Comment by jgrahamc | Hacker News Reader

But, without pointer arithmetics or, despite many claims, pass-by-reference, Go's "pointers" feels like a more flexible form of Java/Ruby/Python/Node/....

It's not clear from the first example if the writer actually understands pointers. The example code passes a pointer to a function and then modifies the pointer, not what it's pointing to. It was no surprise to me that this wouldn't modify the original thing the pointer was referencing. If they wanted to modify the pointer itself then they should have passed a * * User not a *User.

Go does, indeed, have pass-by-reference (use a pointer) or pass-by-value (don't use a pointer).

View on HN

Gos lack of pointer arithmetic is one of the design decisions that allows go to be memory safe (http://en.wikipedia.org/wiki/Memory_safe) . If you need need to be naughty with pointers you can use the "unsafe" package. But some environments like GAE or Go playground do not allow this.

Also some of the built-in types like channels and maps are reference types (so they are always passed by reference).

Everything in Go is passed by value, even the "reference types". Those types are called reference types because they hold a reference to some value in memory, exactly like a pointer.

If they were passed by reference, then we would expect this playground snip to print "false": http://play.golang.org/p/r6naknvzng

You are correct, I was not being clear. They are not Go reference types are not reference types in the same way that they are in other languages.

When you pass a slice around are are really passing a small struct around by value (http://golang.org/pkg/reflect/#SliceHeader), and it is that struct that contains the pointer to the data.

I understand what a pointer is, but it's entirely possible that I still don't grok Go. Before writing that, I did try:

    func main() {
      u := &User{Name: "Leto"}
      Modify(&u)
    }

    func Modify(u **User) {
      u = &User{Name: "Paul"}
    }

With no luck.

Nope, looks like you don't understand pointers. You're still modifying the passed-by-value pointer to a pointer, and not the thing that it points to.

ah! That makes a lot of sense actually.

If you want to cause side effects in a function, you have to dereference something. (or call another evil function)

The only exception being dot operators, which implicitly dereference their left hand argument.

   (&x).whatever() == x.whatever()

I wish go had used arrow notation now. Explicitly marking side effects is a good thing.

Is this what you want? http://play.golang.org/p/Pt1D_ICJu5

Yes. Thank you! I completely admit that I'm wrong. Nevertheless, 1 thing to add. Maybe I'm being pedantic, or maybe I still don't get it, but even Go's FAQ says "everything in Go is passed by value". If you call what Go does pass by reference, what do you call what C#'s "ref" keyword does?

Besides the few special built-in types that are passed by reference, everything else if passed by value. (Even "reference types" are actually structs that are passed by value (http://golang.org/pkg/reflect/#SliceHeader). And not reference types in the sense they are in other languages.

For example if you pass a struct, you are passing it by value, but if you pass a pointer to that struct, you are also passing by the argument by value. Why? Because even though the pointer contains a reference to the struct as its value, the pointer itself (which is the same as any other integer datatype to the computer) is being passed by value.

If your not familiar with pointers and C and languages with reference values like C++/Java this distinction isn't going to mean much to you however.

Yeah, I wish they hadn't called them "Reference types" - I think it's confusing. They're just value types that happen to have a small value and a pointer to the bigger data.

I would agree with that sentiment. I would have called them "auto-alias types" maybe or "auto-clone types"?

Aliasing.

There's really no such thing as pass by reference in Go. It's all pass by value. However, the value may be a pointer to other data that doesn't get copied. This is how pointers, maps, slices, and interfaces work (if you're passing an interface to another function that also takes an interface that is. If you're passing a non-interface value into a function that takes an interface, the value gets copied when it is wrapped in the interface... again, that value might be just a pointer or other small thing, or if you don't structure the code right, it might be a whole lot of data.. but usually it's not, because we write code specifically not to copy much data).

(I am not a .net developer) But having read the msdn description of the ref keyword

http://msdn.microsoft.com/en-gb/library/14akc2c7(v=vs.71).as...

I would expect that refs are roughly equivalent to the following

http://play.golang.org/p/3cwx5Qofc8

Where the commented out code represents the .net equivalent. I would expect that the .net compiler simply rewrites your code for you to hide the slightly tricky messing about with pointers. So the .net ref looks like a bit of syntactic sugar over what you were trying to do in your post.

Enjoyed your article. I think that you are a little off the mark with respect to pointers though.

The simple solution to your first example is to simply write to the Name field of the struct being pointed too.

http://play.golang.org/p/D3t0Iv8oG4

If you want to do complex pointer meddling (and replace the entire struct) you need this syntax.

http://play.golang.org/p/tMwHC-k-bu

As a side note I have personally used pointers to interfaces for doing search tree reordering. You can really do a lot of useful pointer operations without pointer arithmetic.

(A link to a quadtree implementation which uses pointers to interfaces, on line 119) https://github.com/fmstephe/location_server/blob/master/quad...

You don't need pointer-to-pointers to replace the entire struct, you can just do this: http://play.golang.org/p/2ZUvuyCtwr

  func main() {
    u := &User{Name: "Leto"}
    println(u.Name)
    Modify(u)
    println(u.Name)
  }
  
  func Modify(u *User) {
    *u = User{Name: "Paul"}
  }

Good point. Thx :)

Looks like C pointer syntax!

Indeed. They are pointers. You just cannot do pointer arithmetic on them.

In declaration the '' goes on the left though. In general Go's syntax inverts the declaration w.r.t C/C++:

    a int   vs  int  a
    b *int  vs  int* b

    type X int  vs  typedef int X

NOTE: you can do unsafe pointer arithmetic using the "unsafe" package. You can convert any pointer to a unsafe.Pointer and then you can convert it to a uintptr.
There are also library functions designed to work with that, for example atomic.AddUintptr that atomically adds an offset to a pointer.
Although not intended as general use, it can be useful in low level library code. Otherwise you can do pretty much everything using slices.

"I understand what a pointer is,"
What are you trying to do, and how would you think it works in your examples? I assume you're trying to change the name of the object being pointed to, but you're just assigning a new value to a variable that is passed to a function. Therefore, when the function returns, that value is 'lost'. How could it ever change the value of a member of the object you're pointing to? I have never written a line of Go in my life, but with the knowledge that Go supports some form of pointers, it's quite easy to trace this back to how it would work in C or C++; it also wouldn't work there, either. Knowing what a pointer is is easy, it's just memorizing a definition - knowing how they work takes some experience.

You're displaying some basic conceptual problems with pointers. A simple Go example:
func main() { u := User{Name: "Leto"} Modify(&u) } func Modify(u *User) { // u = &User{Name: "Paul"} // you could, but why? u.Name = "Paul" }
I mean, if you read your code for main, you're saying "Declare u to be a pointer to a new User. Then call modify with the address of u... aka, the address of the pointer that points to the actual User object"...
This is pretty much basic pointer stuff, the same as you would do in C: runnable: http://codepad.org/TeUZi1Wp

I wanted (and miserably failed) to show that Go wasn't pass by reference (which a lot of people, including on HN, insist that it is, even though the docs and the behavior are quite clear). Of course the simplistic example doesn't make much sense, why not just reassign u.Name? My point is that you can't simply reassign u (as other have pointed out, you can by dereferencing a pointer to a pointer...which is still pass by value)

I think you're still pretty fundamentally confused.
RE: "Go is pass by reference": I don't see anyone claiming that. The top comment is trying to be nice by saying that you can emulate pass by reference by passing a pointer (but you're really just passing the pointer by value).
I mean, what do you think this Java code prints (objects are references, but passed by val):
Runnable: http://rextester.com/JBZCLG13581
You should also consider the good comment above displaying how you actually CAN do REAL swapping in Go: http://news.ycombinator.com/item?id=5357959 (try that in Java... heh)

If you write that in C#, and declare the argument as "ref User u", it'll print "newName". Which is what I think pass by reference is. Java and Go (and C) are pass by value.
When I started learning Go, I kept seeing people talk about pass by reference, so I assumed it really did pass by reference (despite being uncommon). I was surprised to find out that it does pass by value.

Well, like I said, I've never seen anyone claim Go as pass-by-reference. That having been said, the spec refers to slices and maps as "reference types" but it doesn't mean they're pass by reference. They're still passed as a pointer, you just don't see it.
You're correct about the "ref" keyword in C#, when used for the arg and parameter, it causes the function or method to act on the same chuck of memory as the alias represented in the caller.

I have never seen Go described as pass-by-reference, especially when it doesn't have references to begin with (in the C++ sense of evaluating what it points to instead of the address itself).

> I understand what a pointer is, but it's entirely possible that I still don't grok Go.
I don't know about you, but I understand pointers from C, and then learning assembly. Go's behavior isn't different from C here.
Also, elsewhere you are discussing pass by value/pass by reference. Technically, C/Go/Java are pass by value. Passing pointers and de-referencing it is how pass-by-ref is emulated. You will notice that the top comment has qualified pass-by-reference with "passing pointers". That is colloquial terminology.

Reply on news.ycombinator.com