не то, что указатель на тип в интерфейсе не nil?
https://go.dev/play/p/017t8TDHVts
https://go.dev/play/p/aomGGddMD7l
Это, конечно, круто, но я хочу пример со структурной типизацией, а тут и динамический, и статический тип одинаковые, это не так весело)
А причём тут структурная типизация? Это ж другое вроде
В этом примере, совместимость типов явно описана. Наверное, не совсем корректно было говорить "пример со структурной типизацией", но я имел в виду ситуацию, когда статический и динамический тип интерфейса - разные.
Ну либо так https://go.dev/play/p/lyvWxlzkyU4 Либо сразу из функции возвращать интерфейс Вообще интересно, в го не принято возвращать интерфейс (если это не error), но из-за таких особенностей иногда приходится вернуть интерфейс дабы не было проблем с != nil
Чего это не принято возвращать интерфейс?
Ну, принято же интерфейс объявлять по месту применения, а не по месту объявления Из-за этого непонятно какой именно интерфейс возвращать, если у тебя их два в разных местах)
Плюс эскейп анализ плохо работает в этом случае, но это уже мелочи
Как раз с кастомным еррор мне кажется логичным объявление где-то в типах интерфейса, и потом во всей структуре его использовать
Еррор может да, а если мы про другие интерфейсы? Тут уже не так очевидно (для меня)
вопрос по поводу эскейп анализа: почему при передаче значения в интерфейс оно всегда escapes to heap?
Понял. Ну я конкретно про возврат интерфейса своего еррора, да
Потому что компилятор не знает что будет происходить с объектом, упакованным в интерфейс Может, ситуацию исправит PGO (если завезут)
Profile-guided optimizations это когда анализуют работу билда?
Когда работающая программа собирает информацию о своей работе. Например, слишком частые вызовы конкретных функций, какая реализация скрывается за интерфейсом, в какие места программа заходит редко и тд И на основе этой информации можно снова скомпилировать программу, но компилятор уже будет знать о твоём коде сильно больше
уже есть pprof, можно к go run прикрутить
Обсуждают сегодня