Приведение типов и type assertion

В прошлом уроке мы закончили честным признанием: any — коробка, из которой компилятор не даёт ничего достать. Положить можно всё, вынуть — ничего: box[0] + 1 не собирается, v.String() не собирается, ошибку компилятор формулирует коротко — «у any нет методов». Стена нарочно высокая: она напоминает, что вы отдали компилятору зрение, когда упаковали значение в пару «динамический тип + значение».

В этом уроке мы возвращаем зрение — вручную, точкой и именем типа. Операция называется type assertion, утверждение типа, и записывается как x.(T): после выражения-интерфейса ставится точка и в скобках тип-претендент. Читается дословно: «утверждаю, что динамический тип значения, лежащего в x, — это T; отдай мне его как T». Если утверждение верно — вы получаете значение в его настоящем типе, и у него снова работают все операции: арифметика, методы, поля. Если неверно — поведение зависит от формы записи, и здесь начинается главное правило урока: у type assertion две формы, безопасная и опасная, и выбирать между ними нужно осознанно.

Type assertion — единственный штатный способ распаковать интерфейсное значение в Go. Дженериков вплоть до версии 1.18 не было, any был единственной корзиной «всё», и весь код стандартной библиотеки распаковывал её именно утверждением типа. Поэтому x.(T) вы встретите везде: в парсерах JSON, в драйверах баз данных, в обработчиках ошибок, в middleware веб-фреймворков, где из c.Request() достают конкретный контекст.

План урока: сначала ok-форма — безопасный вопрос «внутри T?», затем одиночная форма и её паника, затем распаковка []any-коробки из прошлого урока, проверка на интерфейсный тип и type switch — переключение по динамическому типу. Напоследок разграничим утверждение типа и приведение числовых типов — операции, которые новички постоянно путают из-за похожего вида. Интерактивы спроектированы под оба движка песочницы; где движки расходятся — честная оговорка.

Вспомним устройство из десятого урока: интерфейсная переменная — не контейнер с данными, а пара из двух слов — указателя на информацию о динамическом типе и указателя (или копии) самого значения. var v any = 42 — пара (int, 42); v = "семь" — пара (string, "семь"). Компилятор при упаковке тип знает и проверяет; после упаковки он его забывает — в этом смысл any. Type assertion — это операция, которая заглядывает в первую половину пары и сверяет её с вашим заявлением.

Синтаксис: x.(T), где x — выражение интерфейсного типа (any, error, fmt.Stringer, ваш собственный контракт), а T — тип-претендент: конкретный (int, string, ваша структура) или интерфейсный (об этом отдельно ниже). Результат операции — значение типа T, то есть после удачного утверждения вы работаете уже не с парой, а с конкретным значением: у него снова есть тип, операции, методы.

Форм две. ok-форма присваивает два значения: n, ok := v.(int) — первое это распакованное значение, второе — булев флаг удачи. Паники не бывает никогда: не совпало — получите нулевое значение T и ok == false. Одиночная форма присваивает одно значение: n := v.(int) — и верит вам на слово: если динамический тип не int, программа паникует с сообщением interface conversion. Первая форма — вопрос; вторая — заявление под ответственность.

Важная деталь, на которой спотываются: x обязан быть интерфейсного типа. Утверждение s.(string) над обычной строковой переменной не соберётся — компилятор и так знает её тип, утверждать нечего. Assertion — операция над парой, а пара есть только у интерфейсов. Отсюда и логика урока: упаковали через any — распаковывайте через assertion; у конкретных типов распаковывать нечего.

Разберём механику неудачи, потому что на ней построены все идиомы распаковки. Если динамический тип пары не равен T, ok-форма v, ok := x.(T) возвращает два честных факта: ok == false и v — нулевое значение типа T. Для int это 0, для string — пустая строка, для указателя — nil, для вашей структуры — структура с нулевыми полями. Нулевое значение — не «ошибка» и не «мусор»: это обычное корректное значение типа, которое вы обязаны игнорировать, пока флаг false. Отсюда железное правило: читайте флаг до значения. Идиома оформляется if-ом с инициализатором:

if n, ok := v.(int); ok { fmt.Println("целое:", n) }

Переменные n и ok живут только внутри ветки — компилятор не даст вам случайно использовать n за её пределами, где флаг не проверен. Это тот же приём, что if err != nil у функций: область видимости сужена до проверенного пути.

Отдельный случай — nil-источник. Если сама пара пуста (var v any), любой вопрос v.(T) в ok-форме отвечает ok == false — паники нет и здесь. Пустая пара не совпадает ни с каким типом, и ok-форма это фиксирует спокойно. Это делает ok-форму пригодной для обработки данных, которым вы не доверяете: входных JSON-ов, значений из внешних API, содержимого карт map[string]any — что бы ни лежало внутри, включая ничего, — программа не упадёт.

И тонкость, которую стоит проговорить: ok == false и «нулевое значение» — это одна ситуация, а не две. Не бывает «успеха с нулём» и «неудачи с нулём» одновременно — вопрос ок-формы всегда ровно один: совпал ли динамический тип. Поэтому нельзя полагаться на сравнение значения с нулём как на признак неудачи — единственный источник правды здесь флаг.

Одиночная форма n := v.(int) — это заявление «я знаю, что внутри». Если заявление верно, форма короче и удобнее. Если нет — программа паникует: interface conversion. Настоящий Go формулирует панику исчерпывающе: panic: interface conversion: interface {} is string, not int — «в паре лежит string, а утверждали int». Сообщение читается как отчёт о преступлении: указан и настоящий динамический тип, и заявленный.

Когда одиночная форма законна? Тогда, когда динамический тип гарантирован логикой программы, а не надеждой. Три честных случая. Первый: вы сами только что упаковали значение и распаковываете его на соседней строке — тогда зачем вообще any, но если слои кода между упаковкой и распаковкой тип не теряли, утверждение верно. Второй: контракт функции обещает, что в any лежит конкретный тип, и это зафиксировано документацией и тестами — так устроены колбэки, где регистрация принимает any, а вызов знает, что передавал. Третий: выше по коду стоит проверка — type switch или ok-форма — и вы внутри проверенной ветки; правда, в этом случае идиома требует переиспользовать уже распакованное значение, а не утверждать повторно.

Анти-паттерн очевиден: «я уверен, что там int, проверять не буду». Уверенность в динамическом типе — это ставка на то, что все вызывающие во всех углах программы навсегда сохранят текущее поведение. Ставка проигрывает: рефакторинг меняет упаковщика, assertion в глубине роняет продакшн в три часа ночи. Паника interface conversion — не «дорога в аду», а честный сигнал, что где-то нарушение контракта между упаковкой и распаковкой; но сигнал дорогой, потому что срабатывает в рантайме, у пользователя.

Правило урока: по умолчанию ok-форма; одиночная форма — осознанное исключение с комментарием, откуда гарантия. В библиотечном коде паника иногда уместна как «невозможное состояние» — но тогда её стоит хотя бы задокументировать.

Вернёмся к коробке []any из прошлого урока — срезу, где в одной корзине лежали int, string и bool. Тогда мы могли её только печатать; теперь распакуем. План простой: идём циклом по срезу, для каждого элемента задаём серию ok-вопросов — «ты int?», «ты string?», «ты bool?» — и обрабатываем первый удачный. Идиома оформляется каскадом if-ов с инициализатором и continue:

if n, ok := v.(int); ok { fmt.Println(n); continue }

continue после обработки — важная деталь: элемент распакован, его вопрос закончен, идём к следующему. Без него каждый элемент проваливался бы во все последующие вопросы (безвредно — флаги false, — но расточительно и мутно).

Каскад ok-форм — рабочий инструмент, и в небольшом коде он честнее всего выглядит. У него есть два слабых места, о которых стоит знать заранее. Первое: элемент, не совпавший ни с одним претендентом, молча пропускается — float64 в коробке не напечатается вовсе; в данных, которым вы доверяете, молчаливый пропуск — потеря, поэтому ниже появится type switch с веткой default, которая ловит «всё остальное» громко. Второе: каскад растёт линейно с числом типов — пять типов, пять if-ов; type switch делает то же самое одной конструкцией. Но для двух-трёх типов каскад читается отлично и не требует выученного синтаксиса.

Третий нюанс каскада — порядок вопросов. Пары «динамический тип + значение» сравниваются с претендентом точно, поэтому порядок if-ов на результат не влияет: int не перепутается с int64, string с bool. Это не range-проверки, а точное равенство имён типов в паре — и к точности мы вернёмся, когда будем отличать assertion от преобразования.

Претендент в x.(T) не обязан быть конкретным типом — им может быть интерфейс. Вопрос s, ok := v.(fmt.Stringer) звучит иначе, чем вопрос про int: не «ты строка?», а «умеешь ли ты печатать себя?». В настоящем Go удача означает: динамический тип пары реализует контракт целиком, и результат s — значение интерфейсного типа fmt.Stringer, готовое к вызову s.String(). Так проверяют не идентичность, а способность: у error-значения спрашивают err.(*MyErr) — «ты моя ошибка?», у любых значений — «ты Stringer?».

Именно ok-форма на error-пути — тот инструмент различения, который обещал одиннадцатый урок в истории с typed-nil. Напомнить связь одной фразой: ловушка была в том, что var e *MyErr = nil; return e даёт вызывающему пару (MyErr, nil) и обманывает `err != nil`. Ok-форма `me, ok := err.(MyErr)` — вежливый вопрос к interface-паре без паники: она различает «моя ошибка с полями» и «что-то чужое» не сравнением с nil, а проверкой динамического типа. В проде это главный способ достать свою структуру из generic-параметра error и прочитать её поля. Разбор самой ловушки не повторяем — он сделан в одиннадцатом уроке; здесь важно, что распаковка — её рабочее продолжение.

Теперь честный сюжет, ради которого тема интерфейсных претендентов не идёт в ранимые блоки. Наши обе песочницы на этом сюжете врут: код var v any = Cat{...} с методом String(); s, ok := v.(fmt.Stringer) обе отвечают ok == false, тогда как настоящий Go говорит true; одиночная форма s := v.(fmt.Stringer) паникует в обеих, хотя в настоящем Go проходит. Проверено пробниками до написания урока. Поэтому утверждение к интерфейсным типам разобрано здесь текстом и quiz-ом, а все ранимые блоки урока утверждают только к конкретным типам — на них оба движка точны. Сверяйте интерфейсные сюжеты локальным go run: это правило курса, и оно продолжает честность прошлых уроков.

Каскад ok-форм решает задачу «спросить про несколько типов», но у Go есть конструкция ровно для этого — type switch, переключение по динамическому типу. Синтаксис узнаёт обычный switch, но в скобках стоит не выражение, а утверждение с ключевым словом type:

switch x := v.(type) { case int: ... case string: ... default: ... }

Читается: «смотри на динамический тип пары, лежащей в v; если это int — работай в первой ветке, если string — во второй, иначе — в default». Главная прелесть конструкции — переменная x: в каждой ветке она уже конкретного типа. В case int компилятор видит int — легальна арифметика и %d; в case string — строка, легальна конкатенация; в default — x остаётся any. Это не «перегрузка» и не магия: switch разворачивается компилятором в каскад утверждений, и в каждой ветке x присваивается результат удачного v.(тип_ветки). Ничего лишнего не напишете: внутри case int вызов строкового метода x не соберётся.

Перечислим свойства конструкции точно. Веток может быть сколько угодно, включая свои структуры — case Cat: легален. default необязателен, но без него незнакомые типы проходят мимо, как в каскаде. Можно писать без переменной — switch v.(type) — когда значение в ветке не нужно, а важен только факт типа. Несколько типов в одной ветке перечисляются через запятую — case int, int64: — тогда x в этой ветке остаётся any: компилятор не знает, которое из двух выпало. И ещё: порядок case-ов, в отличие от if-каскадов с диапазонами, для точных совпадений не важен — вопрос всегда «равен ли динамический тип этому претенденту», а не «попадает ли в диапазон».

Канонический вопрос: когда type switch, а когда ok-форма? Один тип-претендент — ok-форма; два и больше, особенно с веткой «всё остальное», — type switch: та же семантика, меньше букв, громче незнакомые типы.

Пришло время развилки, на которой путаются даже опытные: чем x.(T) отличается от T(b)? Внешность почти совпадает — скобка с типом; природа противоположная. Приведение типов (conversion) int(3.9), float64(i), string(rune) — операция над значением: компилятор берёт биты числа и перетолковывает их в новом типе, меняя представление — срезая дробную часть, расширяя или сужая разрядность. Она происходит полностью на стадии компиляции, у неё нет ни «динамического типа», ни флага удачи, ни паники. Для любой пары числовых типов она легальна всегда: int(3.9) даст 3, int64(i) даст то же число в широком типе, byte(300) даст 44 — с усечением по модулю, без вопросов.

Type assertion x.(T) — операция над парой: она ничего не перетолковывает и не преобразует, а смотрит на динамический тип и требует точного совпадения имён. В паре лежит int — вопрос x.(int64) провалится, хоть значения и совместимы: int и int64 — разные динамические типы, пары (int, 42) и (int64, 42) — разные пары. Провал ok-формы — флаг false; провал одиночной формы — паника. Компилятор здесь бессилен: он забыл динамический тип, проверка — рантайм.

Отсюда практическая таблица решений. Значение уже есть, нужно другое представление (целое ↔ дробное, ширина разрядности) — преобразование T(b): законно, компиляция, потеря точности на вашей совести. Значение лежит в интерфейсной паре и нужно обратно конкретным типом — assertion x.(T) с ok-формой. Между int и int64 через any: сначала assertion к родному типу — n, ok := x.(int) — потом преобразование int64(n), если нужно. Смешивать шаги нельзя: x.(int64) при паре (int, …) — ложь, а int64(пара) — вообще не собирается: преобразование не работает над интерфейсами, ему нужно значение.

И третья сила, живущая рядом: strconv.Atoi("42") — это ни то, ни другое, а парсинг: строка разбирается в число, ошибка приходит обычным err-ом. Если данные приходят текстом, вам нужен strconv, а не assertion — утверждение не умеет превращать строку в число, оно вообще ничего не превращает.

Соберём словарь урока в одну карту, потому что запрос приведение типов golang приводит на эту страницу сразу за несколькими словами, а в русском тексте «приведение типов» часто называют всё подряд: и conversion, и assertion, и парсинг. Разведём понятия окончательно.

Преобразование (conversion) — T(b) над значениями: числовые пары, именованные типы поверх базовых (type Celsius float64 и обратно), строка в срез байт. Компиляторная операция, всегда легальна для совместимых представлений, потеря точности возможна, динамический тип не участвует.

Утверждение (type assertion) — x.(T) над интерфейсной парой: извлечение динамического типа. Две формы: ok-форма без паники и одиночная с interface conversion. Работает только с интерфейсами: у конкретных значений пары нет, утверждать нечего.

Type switch — switch x := v.(type): синтаксическая упаковка серии утверждений, в каждой ветке x конкретного типа, default ловит незнакомцев.

Парсинг — strconv: текст в число и обратно, ошибка через error. Ни пара, ни преобразование тут не виноваты — это разбор формата.

Старая форма пустого интерфейса interface{} из прошлых уроков — тот же any: упаковка через него, распаковка через те же инструменты; исторически в старом коде вы встретите и switch x := v.(type), и v, ok := x.(int) в паре с interface{} — правила полностью совпадают. И общий критерий выбора, наследуемый от одиннадцатого урока: чем раньше значение перестаёт быть any, тем лучше — распаковывайте у границы и дальше несите конкретный тип; assertion — мост из мира незнания в мир гарантий, и чем короче мост, тем дешевле проверка. Четыре инструмента, четыре задачи: не занимайте их чужую работу.

Виток закрыт полностью: коробка any, которую одиннадцатый урок собрал, а десятый объяснил на паре «динамический тип + значение», научилась открываться. Ok-форма v, ok := x.(T) — безопасный вопрос с флагом; одиночная x.(T) — заявление под ответственность с паникой interface conversion; type switch — перебор претендентов с громким default; преобразование T(b) — соседняя, но другая операция над значениями. Плюс инструмент различения своей ошибки err.(*MyErr), продолжающий историю typed-nil. Контракт словаря прост: упаковка — по одну сторону точки, распаковка — по другую.

Что дальше по курсу? Тринадцатый урок — дженерики: type parameters и constraints. Это второй, более молодой ответ языка на ту же боль: «одна функция — много типов». Где any требовал распаковки assertion-ом и возвращал проверку в рантайм, дженерик func Map[T, R any](s []T, f func(T) R) []R держит типы в сигнатуре: компилятор знает их на этапе сборки, и ни пары, ни утверждения, ни паники не нужно. Двенадцатый урок дал инструменты распаковки, тринадцатый покажет, когда распаковка не нужна вовсе. Дальше — пакеты и модули (весь курс) и ошибки со сквозной упаковкой, где ok-форма к *MyErr из сегодняшнего статичного блока вырастет в полноценные errors.Is и errors.As.