I would add that because the dynamic type of an interface value is not known at compile time, a variable of interface type really can't (in general) have a specific size. If a function has an interface parameter, it must be possible to pass a value of *any* size to it. So even aside from what the current implementation does - any Go compiler must, in general¹, consider interfaces to be pretty-much-pointers.
"in general" because a compiler can, of course, determine that in a certain scenario the value doesn't have to be packed and pass it as-is. This is an optimization sometimes called "devirtualization". But in the general case, a compiler can't prove that (e.g. the dynamic value in an interface could be determined by a random number generator), so it will always be an optimization and the default always has to be a form of boxing into a constantly sized shape. All of this is a good indication, from first principles, that you don't have to worry about the size of the dynamic value when passing it. What's more, in general you should trust the author of the package you are using to give you a reasonable implementation of an interface. You shouldn't worry what the dynamic type and value in an interface is, unless you have very good reason to care. In this case, unless you notice that your code is very slow if you don't use a pointer (that would be "a very good reason to care"), you shouldn't optimize it. And if you notice, you should open a bug against that package :) Though as established, you won't. On Sat, Jun 5, 2021 at 11:18 PM Ian Lance Taylor <i...@golang.org> wrote: > On Sat, Jun 5, 2021 at 2:15 PM Joshua <joshua.oconno...@gmail.com> wrote: > > > > My question is general, but for ease of communicating I'll use the > specific example I ran into. > > > > I'm very new and for my first project I'm working with the bleve library > [https://pkg.go.dev/github.com/blevesearch/bleve]. > > > > One function I need, "Open", returns an interface, "Index". > > > > I'd like to write my own function to act on this interface, and given > that I have no idea what the dynamic value of the interface is, my first > instinct is to rather pass a pointer to the returned interface into my > function. > > > > However, I see lots of calls of "If you're using pointers to interfaces > a lot, you probably don't understand them". > > > > Well, what am I not understanding? > > My worry is that I have no idea what dynamic type is lurking within the > interface, if it's a pointer to a struct, then I obviously don't mind > passing it into my function. > > > > However if it is in fact a humungous 1GB struct, then I really really > don't want to be copying that around willy-nilly. > > > > Is there a way in general to avoid this, without looking at the library > source code to see what the actual concrete type is? > > In the current implementations a value of interface type is always a > pair of pointers. Even if the value of interface type happens to > refer to a 1GB struct, copying the interface value, including passing > it to a function or returning it from a function, always just copies > two pointers. > > 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/CAOyqgcUuv_qrrG8%3DdCQZv0%2BrKbnbW60XdOCwjp8M3EdOCxCNkw%40mail.gmail.com > . > -- 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/CAEkBMfEjuaRnd33SRtvyH81N9G0xtL7JZqjqg_BKspMj6vujFw%40mail.gmail.com.
