Анатомия интерфейсов в Go

В процессе знакомства с Go я нашел в документации пример:

func returnsError() error {     var p *MyError = nil     if bad() {         p = ErrBad     }     return p // Will always return a non-nil error. }

После его просмотра меня заинтересовало, почему returnsError всегда будет возвращать не non-nil error?

Переменные в Go всегда инициализируются значением. Это относится и к интерфейсам. Стоит отметить, что интерфейсы реализованы в виде двух элементов: тип(T) и значение(V). Это достаточно поверхностное определение, которое чуть дальше мы разберем. Значение интерфейса будет nilтолько в том случае, если Vи T оба будут nil.

Есть интересный момент, а именно случай, когда V=nil, а T!=nil. В таком случае никакие проверки интерфейса на nil нам не помогут. А ведь именно этот сценарий и происходит в returnsError.

Мне стало интересно, как именно эти проверки проходят в Go.

type Word struct { name     string priority uint }  type Foo interface { foo() }  func (w *Word) foo() { fmt.Println("call foo()") }  func (w *Word) noFoo() { fmt.Println("call noFoo()") }  func call(f Foo) { if f != nil { f.foo() } else { fmt.Println("f null") } }  func main() { var f1 *Word call(f1) }

В приведенном выше коде есть проверки. Все отрабатывает без ошибок. Вывод будет следующим:

call foo()

Кажется несколько странным, ведь передали nil и вообще ожидалось что либо не пройдет проверки на nil, либо выстрелит при выполнении.
Давайте разбираться.

Функция call принимает интерфейс Foo. Как вообще происходит преобразование указателя Word к интерфейсу Foo?
Упрощенно интерфейс выглядит следующим образом:

Интерфейс:
1. статический тип
2. динамическая информация:
— динамический тип
— динамическое значение

В нашем примере статическим типом будет Foo, динамическим типом Word, значением nil.

Посмотрим более подробно.

Языки с методами можно разделить на два вида: создают таблицы виртуальных методов (например C++) или выполняйте поиск метода при каждом вызове (Smalltalk). Во втором случае для оптимизаций используется кеширование. Go находится посередине: у него есть таблица методов, но вычисляется она во время выполнения.

Из чего же состоят интерфейсы в Go?

type iface struct { tab  *itab data unsafe.Pointer }

data — это непосредственно наш f1 из примера. Вся информация по методам, типам и прочему скрывается в tab — интерфейсной таблицей (interface table).

type itab struct { inter *interfacetype _type *_type hash  uint32 // copy of _type.hash. Used for type switches. _     [4]byte fun   [1]uintptr // variable sized. fun[0]==0 means _type does not implement inter. }

Обратите внимание, что itab соответствует статическому типу интерфейса (Foo), а не динамическому (Word). Для большей точности она соответствует паре Foo—Word. Поэтому внутри itab будут только методы, которые удовлетворяют интерфейсу Foo и noFoo здесь не будет.

inter — содержит метаданные о статическом типе интерфейса.
_type — о динамическом типе
fun — набор указателей на методы интерфейса. является variable sized.

Откуда берется itable?

itab — представляет собой своего рода ключ значение, а именно соответствие статического типа динамическому (помните говорил выше проFoo—Word ?). В больших программах типов и интерфейсов великое множество. И не все комбинации нужны. Для этого в Go компилятор создают несколько таблиц описания типов. В первой содержится список методов для конкретного интерфейса . Во второй, какие методы содержат динамические типы. Наш itable — это соответствие между этими двумя таблицами. itable кэшируется после создания, так что это соответствие нужно вычислить только один раз.

Как же метод f.foo() будет вызываться и почему нет ошибки?

Будет некоторый аналог:

f.tab.fun[0](f.data)

Мы разобрали, что будет в fun[0] (единственный метод нашего интерфейса Foo) и что содержит в data (сам объект Word, в примере мы передали указатель на него неинициализированным — nil).
В некоторых языках (например C++) для методов есть такое понятие как this-call. Оно означает, что первым скрытым параметром любого метода идет указатель на сам объект(this). И если нужно изменять/читать поля объекта мы к ним обращаемся неявно через this. При этом есть статические методы, которые можно вызывать без создания объекта — для таких методов this не передается неявно т.к. не нужен.
В нашем примере как раз это и получается. Метод foo никак не взаимодействует с Word. И поэтом f.data (которая nil) не используется и программа корректно завершает работу.

Если изменим реализацию метода — то все упадет как надо:

func (w *Word) foo() { fmt.Printf("call foo(): %s\n", w.name) }

Ранее было утверждение:
Значение интерфейса будет nilтолько в том случае, если Vи T оба будут nil. Если теперь говорить про код: значение интерфейса будет nil только в том случае, если data и _type равны nil одновременно, ведь вариант когда только data равно nil, вполне корректен. Нулевое значение интерфейса, которое не содержит значения как такового, не совпадает со значением интерфейса, содержащим нулевой указатель, в чем мы убедились, посмотрев структуры.

Спасибо за внимание.