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

[SnakE]

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.

[SnakE]

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.

[jesse.dailey]

> 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. :)

[Russ Cox]

> 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]

If so, is it similar to the OOP's singleton?

[Russ Cox]

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