On Wed, Nov 13, 2019 at 12:23 PM Brian Candler <b.cand...@pobox.com> wrote: > > > 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].
At the level at which we are talking, a value will typically be on the stack or in registers, but a value converted to an interface type will typically be on the heap. So that is the copy to which I referred: from the stack to the heap. There are various exceptions and conditions, but that is the most common case. > 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. I don't mean to say that it is The Go Way. I was only trying to provide a plausible reason why the code in the blog post was written that way. It would be absolutely fine to use a value rather than a pointer; that would be just as much The Go Way. Ian -- 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/CAOyqgcVNTy1fjZ4mWfgK_N0OnSsikjiJJR-o5fFjCNDy3A85FA%40mail.gmail.com.
