6 ms·
> One generic reason to use a specific type (heh) is to avoid resolving the interface on every use. Aren't Go interface checked at compile time? I thought only
by sudhirj 11y ago
> One generic reason to use a specific type (heh) is to avoid resolving the interface on every use.
Aren't Go interface checked at compile time? I thought only interface casting happened at runtime.
- brandonbloom 11y agoCasting one interface type to another involves a dynamic lookup, since you don't know what concrete type you're going to have at runtime. See http://research.swtch.com/interfaces http://research.swtch.com/interfaces for context.
- mvdan 11y agoThis might be relevant: https://github.com/mvdan/interfacer/issues/19 https://github.com/mvdan/interfacer/issues/19 And thanks for the link! That should be useful to make a decision on what to do in that issue.
- jerf 11y agoChecking that a value put into an interface type conforms to the interface type is done at compile time, so modulo issues with "nil" you can't have an interface type where the wrapped type will turn out not to have the desired method at run time. However all method invocations on that interface will pass through a dynamic lookup, like going through a vtable in C++. It's one of the things that makes the people who are very, very serious about absolute speed not use Go. I imagine it also prevents inlining in most or all situations. (I don't know exactly how hard the compiler will try to notice that something is nominally in an interface value but it can be sure it is actually a concrete type. My guess is "not at all".) Given that inlining is Go's big optimization technique, that can be another generic reason to use a specific type instead of an interface.