2

I have read this article which indicates a double tuple structure, but it is unfortunately light on implementation details, which is what I am looking for.

So... how are interfaces implemented in Go?

Pure guesswork on my part:

  • It cannot be a v-table in the C++ sense, because the interface is implicit - a struct doesn't know it conforms to an interface when compiled, only when passed to a function taking an interface does this actually happen.
  • I don't think it can be static polymorphism - every function that takes an interface parameter would have to be compile-time aware of every type that might be passed to it and I don't think that's true either.

What else is left?

user
  • 107
  • 2
SRNissen
  • 151
  • 5
  • 1
    I had the same question as you and wrote down my findings here: https://lukasatkinson.de/2018/interface-dispatch/#fat-pointers (but might be partially outdated by now). Yes there's a vtable, but its tracked *outside* of the object, and it may be created lazily by the language runtime. – amon Apr 27 '23 at 15:36
  • Interesting! I assume that in turn this (edit: the fat pointer you write about) implies that a function using interfaces always does pass-by-reference? (Not that this would be a loss compared to any other language I know but that wasn't what I thought was going on in go) – SRNissen Apr 27 '23 at 15:43
  • Based on what I found with a quick search, Go passes references by value similar to how it works in Java and Python. – JimmyJames Apr 27 '23 at 15:54
  • @amon lmao check this off topic question lock. Clearly I must have been "asking for assistance in explaining, writing or debugging code, or using coding tools," and any day now I'm sure somebody will be able to helpfully explain which one of those they mistakenly thought I was doing. – SRNissen Apr 27 '23 at 19:11
  • I think it's a good question and on-topic. I have voted to reopen. You might want to edit the question to be less conversational and perhaps inline relevant details of the article. Often the targets of links can vanish so it's best to put the essential details into the text of the question. – JimmyJames Apr 27 '23 at 19:38
  • The problem really is that the article explains barely anything, which is why I decided to ask :D But there's probably space for putting the actual question into the body of the text. – SRNissen Apr 27 '23 at 19:42
  • 2
    Sometimes it seems like every single question is off topic for here. Voted to reopen. – pjc50 Apr 28 '23 at 08:33
  • I'm really interested in this question. I have zero experience with Go (the language) and very little knowledge about it but the question you are asking seems really relevant to my interests. If I edit your question, would that be a problem for you? – JimmyJames Apr 28 '23 at 21:26
  • Go ahead - though you may also want to look at [this article](https://research.swtch.com/interfaces) that I got when I asked the same question in [this reddit thread](https://www.reddit.com/r/golang/comments/130pkav/how_are_interfaces_implemented_under_the_hood/). – SRNissen Apr 29 '23 at 10:25

1 Answers1

0

In Swift, there are (kind of) objects that represent interfaces. Say an interface has three functions. Then the interface object has three function pointers and a bit of storage. When you pass an object to a function expecting an interface, an interface object is created, three function pointers are stored, and the data is stored. I think (from memory) that for class instances a reference is stored, for small structs the contents of the struct, and for large structs a pointer is allocated.

Sounds a reasonable way to do this, so Go might do the same. You can convert such an object back to the original type if you know the type. A function using the interface object needs no knowledge of the actual type. Called an “existential interface”, so an interface that actually exists as an object.

gnasher729
  • 42,090
  • 4
  • 59
  • 119