why can a variable of type T call methods of *T?

[T L]

This makes people think all methods of *T are also methods of T, so the method set of T is a superset of the method set of *T.
In fact, it is just the contrary.

[Matthew Dempsky]

Are you asking where in the Go spec allows that, or what the rationale for allowing it is?

For the former, see this sentence from https://golang.org/ref/spec#Calls:

"If x is addressable and &x's method set contains m, x.m() is shorthand for (&x).m()"

For rationale, it's because writing (&x).m() everywhere would be inconvenient.  Just like how Go allows p.f as shorthand for (*p).f for accessing struct fields.

On Wed, Jul 13, 2016 at 9:15 AM, T L <tapi...@gmail.com> wrote:

This makes people think all methods of *T are also methods of T, so the method set of T is a superset of the method set of *T.
In fact, it is just the contrary.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[T L]

On Wednesday, July 13, 2016 at 11:35:52 PM UTC+8, Matthew Dempsky wrote:

Are you asking where in the Go spec allows that, or what the rationale for allowing it is?

For the former, see this sentence from https://golang.org/ref/spec#Calls:

"If x is addressable and &x's method set contains m, x.m() is shorthand for (&x).m()"

For rationale, it's because writing (&x).m() everywhere would be inconvenient.  Just like how Go allows p.f as shorthand for (*p).f for accessing struct fields.

I just feel the benefit of shortening (&x).m() to x.m() is smaller than the confusion it brings.
 

[Matthew Dempsky]

On Wed, Jul 13, 2016 at 9:52 AM, T L <tapi...@gmail.com> wrote:

I just feel the benefit of shortening (&x).m() to x.m() is smaller than the confusion it brings.

That's an interesting feeling.  How much have you used Go so far?

Either way, it's not something we can change now without breaking Go 1 compatibility.

[Jaana Burcu Dogan]

On Wed, Jul 13, 2016 at 8:52 AM, T L <tapi...@gmail.com> wrote:

On Wednesday, July 13, 2016 at 11:35:52 PM UTC+8, Matthew Dempsky wrote:

Are you asking where in the Go spec allows that, or what the rationale for allowing it is?

For the former, see this sentence from https://golang.org/ref/spec#Calls:

"If x is addressable and &x's method set contains m, x.m() is shorthand for (&x).m()"

For rationale, it's because writing (&x).m() everywhere would be inconvenient.  Just like how Go allows p.f as shorthand for (*p).f for accessing struct fields.

I just feel the benefit of shortening (&x).m() to x.m() is smaller than the confusion it brings.

In the early days of my experience with the language, these two shorthands became less confusing the moment I acknowledged their existence and I should never refer to the variable name to determine its type. Then, I stopped making assumptions whether the instance is *T or T as I read code and I began to refer to the declaration. It might be a bit tedious to jump back and see the actual type of the instance but with editor plugins, it is not bad. IMHO, without these shorthands, code becomes significantly harder to read. That's a fair compromise.

[mortdeus]

Pointers are in general a very confusing concept. (especially when you get to the fun part of having pointers to pointers or pointers to structs full of their own internal pointers.)

Go is a language designed to make the development process more streamlined and efficient. There are several key aspects comprising this issue of developer productivity when it comes to a language's design. Go works well as a language because on the one hand it enforces developers to be explicitly specific about their intent in some areas while being implicit in others; which is to say that it takes the opposite approach used in most typical mainstream languages. For example, explicit type assignment is something other languages will implicitly infer the intent of the developer while type referencing is something other language compilers require explicit declaration do to the complexity of how data type can be stacked on top of each other whilst containing pointers to other objects with similar inherent complexity embedded within it too.  

The language is designed in such a way where you write code that is sane while keeping you from going insane.

The issue with C++ is that you would sit there and compile code, go to compiler only to have the compiler complaining at you saying "uhhh don't you mean to say, that guy? Look, I can't work under these conditions."  which is to say, the compiler bitches at us for directing it to a sign that points in the direction of the town it's looking to get to.

The fact is our directions work* and yet it wasn't specifically what the compiler is asking for but we assumed it was smart enough to infer on it own which way to go.


1. so long as its not a sign that points <--> with towns who both refuse to change the name they both have taken a fancy to. lol