Why cannot call pointer method on composite literal.

[David DENG]

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]

A composite literal in an expression is *not* addressable. The very
special form of
a := &A{...}
is a special case.

[David DENG]

I cannot find your words in the specs.

David

[Dave Cheney]

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]

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]

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]

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]

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]

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]

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]

This is not a good analogy I think, since you can take the address of int like this:

i := &Int(0)

David

[Dave Cheney]

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]

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]

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.