Why cannot call pointer method on composite literal.

2341 views
Skip to first unread message

David DENG

unread,
Jun 25, 2013, 12:11:56 AM6/25/13
to golan...@googlegroups.com
Since composite literal is addressible why this is not allowed (try this http://play.golang.org/p/UJC10_AZJ_) :

A{I: 1}.Print()

prog.go:23: cannot call pointer method on A literal 
prog.go:23: cannot take the address of A literal 

Any confusion in some situation?

And the second line is confusing since we can do that.

David

David Symonds

unread,
Jun 25, 2013, 12:13:58 AM6/25/13
to David DENG, golan...@googlegroups.com
A composite literal in an expression is *not* addressable. The very
special form of
a := &A{...}
is a special case.

David DENG

unread,
Jun 25, 2013, 12:17:48 AM6/25/13
to golan...@googlegroups.com, David DENG
I cannot find your words in the specs.

David

Dave Cheney

unread,
Jun 25, 2013, 12:19:46 AM6/25/13
to David DENG, golang-nuts
http://golang.org/ref/spec#Address_operators

You already have the solution in your original post on line 17
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

David DENG

unread,
Jun 25, 2013, 12:32:39 AM6/25/13
to golan...@googlegroups.com, David DENG
You guys mean this line?

As an exception to the addressability requirement, x may also be a (possibly parenthesized) composite literal.

How this leads to "cannot call pointer method on A literal" and "cannot take the address of A literal"?

Since paranthesed version works, why the one without parantheses failed?

David

Dave Cheney

unread,
Jun 25, 2013, 12:35:10 AM6/25/13
to David DENG, golang-nuts
Because the parentheses remove the ambiguity

a := &A{...}.Something()

What is a, the value of taking the address of the return value of
A.Something() or the value of *A.Something() ?

David DENG

unread,
Jun 25, 2013, 12:46:55 AM6/25/13
to golan...@googlegroups.com, David DENG
It seems the specs does not define the precedence of the address operaton. If given that, there should be no ambiguities. &(A{...}.Something()) is illegal in current compiler. so not the ambiguity problem.

And my question is A{...}.Something() does not has ambiguities, why not allow?

David

Dan Kortschak

unread,
Jun 25, 2013, 12:53:37 AM6/25/13
to David DENG, golan...@googlegroups.com
On Mon, 2013-06-24 at 21:46 -0700, David DENG wrote:
> And my question is A{...}.Something() does not has ambiguities, why
> not allow?

It's not addressable until it's been assigned to a variable. It's the
same as why you can't do something like Int(0).String() where type Int
int; func (i *Int) String() string {...}:

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

Rémy Oudompheng

unread,
Jun 25, 2013, 12:57:11 AM6/25/13
to David DENG, golang-nuts


Le 25 juin 2013 06:47, "David DENG" <david...@gmail.com> a écrit :
>
> It seems the specs does not define the precedence of the address operaton. If given that, there should be no ambiguities. &(A{...}.Something()) is illegal in current compiler. so not the ambiguity problem.
>

It's not about ambiguity, in your expression there is a single operator '&'. the dot is not an operator.

> And my question is A{...}.Something() does not has ambiguities, why not allow?
>

The goal of the language is not to define the scope of what it can guess you wanted to write.
Adding exceptions to the rules adds more special cases to the specification, which complicates the language instead of simplifying it.

Rémy

David DENG

unread,
Jun 25, 2013, 1:02:07 AM6/25/13
to golan...@googlegroups.com, David DENG
A{...} is a struct, &A{...} is a pointer to the value, go do auto addressing for pointer receivers. So it is very clear A{...}.Method() shoud be legal under normal understanding.

Only not allowing it generates exceptions, which leands complications.

David

David DENG

unread,
Jun 25, 2013, 1:04:51 AM6/25/13
to golan...@googlegroups.com, David DENG
This is not a good analogy I think, since you can take the address of int like this:

i := &Int(0)

David

Dave Cheney

unread,
Jun 25, 2013, 1:05:43 AM6/25/13
to David DENG, golang-nuts
On Tue, Jun 25, 2013 at 3:02 PM, David DENG <david...@gmail.com> wrote:
> A{...} is a struct, &A{...} is a pointer to the value

This is not correct

A{...} is a compact literal, &A{...} is also a compact literal.

Dan Kortschak

unread,
Jun 25, 2013, 1:11:09 AM6/25/13
to David DENG, golan...@googlegroups.com
On Mon, 2013-06-24 at 22:04 -0700, David DENG wrote:
> This is not a good analogy I think, since you can take the address of
> int like this:
>
> i := &Int(0)

You may want to try that and check you've got it correct. If you want
the address, you need to x := Int(0); i := &x.

Dan Kortschak

unread,
Jun 25, 2013, 1:12:26 AM6/25/13
to David DENG, golan...@googlegroups.com
On Mon, 2013-06-24 at 22:02 -0700, David DENG wrote:
> So it is very clear A{...}.Method() shoud be legal under normal
> understanding.

It is if Method is defined on the value rather than the pointer.

Reply all
Reply to author
Forward
0 new messages