> the current implementation of interfaces is that they always store pointer > values. If you store a non-pointer value in an interface, that value > is copied into memory, and a pointer to that memory is stored in the > interface.
I don't understand where you say "that value is copied into memory". If we're talking about a value that already exists, surely it just obtains a pointer to it, without any copying? In other words: if you return a pointer value, then to convert it to an interface type it has to box it as [*T, ptr]. If you return a concrete object, then it has to take a pointer to that object, and box it as [T, ptr]. To my mind, the advantage of a concrete object is that it cannot be nil; if it's used as an interface value, there's only one possible way it can be nil. If you return a pointer to satisfy an interface then there are two ways it can be nil: a nil interface value, and a non-nil interface value containing a nil *T value. It was a big source of confusion to me initially :-) Still... if returning a pointer to an error is The Go Way, I guess I'll do that. It would be nice if the documentation was more explicit about this. Cheers, Brian. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b6efcb16-0cf6-42f0-b796-0c027c227d77%40googlegroups.com.
