[go-nuts] Should I care about return T or *T

Yes. You need *T if you want to modify it's fields, just T if you only to
read them.
"Every thing in Go is referred by value"

The general problem depends on whether you want the caller to modify the
Item?
and in some cases, you have to return a pointer, for example, you can't
pass sync.Mutex
by value, so if the struct embeds a Mutex, you have to pass it by reference
(pointer).

On Mon, May 27, 2013 at 12:05 AM, Nguyên Nguyễn Văn Cao
wrote:
could do something like this:
   itms, err := GetAllItem()
   if err != nil {}
   return &itms[len(itms)-1]

(...)
As you might expect, there really isn't a single answer; it depends on
what an Item is, and how the data is expected to be moved/copied in
the algorithms that use it. With []Item, all the data is contiguous in
a single block, which is a significant advantage. But then, it means
that when you append an item to the slice, you're really appending a
copy of it, which isn't always okay. Also, if you do a lot of item
shuffling within that slice or other operations that force copying the
whole item rather than a pointer, it might compromise that initial
advantage.

In the end, as most things doing the best requires context. So, as a
rule of thumb, until you know best I suggest using []*Item whenever
you do need to preserve the original value instead of having a copy of
it, and []Item otherwise. Then, observe and profile to understand what
is going on.
That's an easy one: no! :-)


gustavo @ http://niemeyer.net

Yes, and referred by value on the other end.
I am not saying anything to the contrary.

http://golang.org/doc/faq#pass_by_value

should help

You /can/, but you shouldn't.

Just because the GC will (usually [1]) find unreferenced items and
make the space available again doesn't mean that you should
make lots and lots of items unreferenced for it to look for: GC
isn't free.

Chris

[1] Conservative collector is conservative.