Re: [go-nuts] composite literals are addressable, function results are not

160 views
Skip to first unread message
Message has been deleted

SnakE

unread,
Nov 26, 2009, 7:42:29 PM11/26/09
to inspector_jouve, golang-nuts
2009/11/27 inspector_jouve <kaush...@gmail.com>
[...]

And it does not mention composite literals. Consider a program:
type foo struct {
 x int;
}
func main() {
 x:=&foo{}; // address of composite literal - legal!
 //y:=&makeFoo(); // illegal indeed
 ...
}
func makeFoo() foo {
 return foo{};
}

I'm trying to figure out what makes composite literals special - in
all other respects, they behave like function results (e.g., they are
not valid lvalues). [ this question arises as a part of investigation
make vs new that is now in progress in another thread ]

AFAIU taking address of a composite literal is a syntactic sugar for an initialized new() and therefore is a completely separate language construct.
Message has been deleted
Message has been deleted

SnakE

unread,
Nov 26, 2009, 10:49:11 PM11/26/09
to inspector_jouve, golang-nuts
2009/11/27 inspector_jouve <kaush...@gmail.com>
I found a way to test it - no, when you say p:=Point{0,0} - it
allocates on stack.
If you say p:=&Point{0,0} - sure, it will be on heap, but this is
natural. So composite literal it's not a "new" in disguise.

I'll quote myself:


taking address of a composite literal is a syntactic sugar for an initialized new()

The "taking address" part is as important as the rest of the sentence.  And "taking address" behavior is exactly something that differs a composite literal from a value returned from a function.
Message has been deleted

jesse.dailey

unread,
Nov 28, 2009, 1:02:48 PM11/28/09
to golang-nuts

> a:=makeFoo(parameters); // creates Foo on stack
> b:=&makeFoo(parameters); // was supposed to create Foo on heap, but
> it's not a valid expression.
>

From my limited understanding, the reason this isn't a valid
expression is that function results are usually in a CPU register, so
they have no memory address.

If you wanted makeFoo to allocate your Foo on the heap, you would have
to use 'new' inside your function, then return the pointer.

If makeFoo allocated Foo on the stack, then returned it, it has to
return it as a copy anyway, because the stack pointer would roll back
after the return, and Foo's original stack-memory location could get
used for something else very shortly.

This is how I remember it working in C anyway... Go could be
different, and C was so long ago I could also just be wrong about
these details. :)
Message has been deleted

Russ Cox

unread,
Nov 29, 2009, 1:16:35 PM11/29/09
to inspector_jouve, golang-nuts
> I'm trying to figure out what makes composite literals special - in
> all other respects, they behave like function results (e.g., they are
> not valid lvalues).

They're special because we decided that the notation was
useful enough for constructors to merit a special case:

Taking the address of a composite literal (§Address operators)
generates a unique pointer to an instance of the literal's value.

http://golang.org/doc/go_spec.html#Composite_literals

Russ

atomaths

unread,
Dec 7, 2009, 5:51:45 PM12/7/09
to golang-nuts
If so, is it similar to the OOP's singleton?

Russ Cox

unread,
Dec 10, 2009, 1:17:55 PM12/10/09
to atomaths, golang-nuts
On Mon, Dec 7, 2009 at 14:51, atomaths <atom...@gmail.com> wrote:
> If so, is it similar to the OOP's singleton?

No. return &Point{1,2} allocates a new Point every
time the statement executes. It does not keep
returning the same one.

Russ
Reply all
Reply to author
Forward
0 new messages