Типы и нулевые значения в Go

Ноль есть у всех, и его делают рабочим

Память при выделении зануляется, поэтому неинициализированных переменных в Go просто не бывает. Числа получают 0, строки - пустую строку, булев тип - false. Указатели, слайсы, мапы, каналы, функции и интерфейсы получают nil.

Из этого выросла целая привычка проектирования: нулевое значение стараются сделать пригодным к работе. var mu sync.Mutex можно сразу блокировать, var sb strings.Builder - сразу писать, var wg sync.WaitGroup - сразу использовать. Конструктор им не нужен, и это считается признаком хорошего пакета: пользователю не приходится помнить про NewЧто-то.

Важное различие внутри самих nil-значений. В nil-слайс можно спокойно делать append - он вернёт слайс с одним элементом, проверено. Из nil-мапы можно читать - вернётся ноль типа значения, и len даст 0. А вот запись в nil-мапу паникует с текстом «assignment to entry in nil map». Разница в том, что append умеет создать массив с нуля, а мапе нужна заранее построенная хеш-таблица.

// Эта паника, кстати, обычная - её ловит recover. Дальше будет случай, когда рантайм убивает процесс без всякой возможности вмешаться, и разницу между двумя ситуациями любят спрашивать.

var ns []int
ns = append(ns, 1)   // [1] - в nil-слайс можно

var nm map[string]int
_ = nm["x"]          // 0 - читать nil-мапу можно
nm["x"] = 1          // panic: assignment to entry in nil map

нулевое значение

то, что лежит в переменной без инициализации: 0, пустая строка, false, nil

рабочий ноль

тип, пригодный к использованию сразу после var, без конструктора

Приведение только явное

Возьми переменную int и переменную float64 и попробуй их сложить - компилятор откажется. Нужно написать float64(i) + f, и это единственный способ. Молча расширять типы Go не будет никогда.

То же самое касается собственных типов. Объявил type Celsius float64 - и значение Celsius больше не подставляется туда, где ждут обычный float64, пока не приведёшь явно. Выглядит занудством ровно до того дня, когда кто-то попробует сложить Celsius с Fahrenheit: они оба float64 внутри, но компилятор не даст их перепутать.

Плата - многословность. Выигрыш - исчезает целый класс тихих ошибок: потеря точности при неявном расширении, переполнение при сужении, смешение доменных величин, физически несовместимых между собой.

// Исключение одно: нетипизированные константы. const x = 5 подставится и в int, и в float64, потому что тип у неё определяется в месте использования, а не в объявлении. Поэтому math.Pi можно умножать на что угодно без конверсий.

явная конверсия

T(v) - единственный способ сменить тип значения

нетипизированная константа

константа без объявленного типа; получает его в месте использования

new, make и встроенные функции

Две функции выделения памяти, и путают их постоянно. new(T) годится для любого типа: выделяет память под T, зануляет и возвращает *T. make работает ровно с тремя типами - слайс, мапа, канал - и возвращает не указатель, а готовое к работе значение.

Отсюда классическая ошибка: new(map[string]int) компилируется и возвращает указатель на nil-мапу. Разыменовал, попробовал записать - получил ту самую панику про nil map. Правильно тут только make(map[string]int).

С Go 1.21 в языке появились три встроенные функции, которые не надо импортировать: min и max берут крайнее из любого числа аргументов, clear опустошает мапу или обнуляет элементы слайса, не трогая его длину. Компилятор знает их сам.

// Тогда же, в 1.21, в стандартную библиотеку въехали пакеты slices и maps: сортировка, поиск, сравнение - обобщённо и без рефлексии, в отличие от старого sort.Slice. А в 1.23 к ним добавились итераторы, и стало можно писать slices.Sorted(maps.Keys(m)) одной строкой. Версии тут лучше не путать: на собеседовании легко назвать 1.21 там, где на самом деле 1.23.

make

создаёт готовый слайс, мапу или канал; только для этих трёх типов

clear

встроенная функция с Go 1.21: опустошает мапу, обнуляет элементы слайса

Как отвечать: «Чему равна неинициализированная переменная и почему нет неявных приведений?»

Неинициализированных переменных в Go нет вообще: любая объявленная получает нулевое значение своего типа - ноль у чисел, пустая строка, false, nil у указателей, слайсов, мап, каналов, функций и интерфейсов. Память при выделении зануляется, поэтому поведение детерминированное, мусора как в C не бывает. На этом свойстве строят библиотеки: sync.Mutex и strings.Builder готовы к работе сразу после var, конструктор им не нужен. Одна тонкость внутри самих nil-значений: в nil-слайс append работает, из nil-мапы читать можно, а вот запись в неё паникует - мапе нужна построенная хеш-таблица, а append умеет создать массив с нуля. Про приведения: Go принципиально не расширяет типы молча, int и float64 в одном выражении не складываются, нужно писать float64(i). Это же касается собственных типов на базе числа - Celsius и Fahrenheit нельзя перепутать, хотя внутри оба float64. Многословно, зато исчезает тихая потеря точности и путаница доменных величин. Единственное послабление - нетипизированные константы: они получают тип в месте использования.

Нулевое значение названо для всех групп типов, следствие для дизайна библиотек показано, разница между nil-слайсом и nil-мапой объяснена причиной, а строгость типов подана как осознанный размен - и отдельно названа граница правила.

На чём валят

• −Путают nil-слайс и nil-мапу: в первый append можно, запись во вторую паникует.
• −Ждут мусор в памяти как в C - в Go всё занулено детерминированно.
• −Пишут new(map[string]int) вместо make и получают указатель на nil-мапу.
• −Думают, что int сам расширится до float64 внутри выражения.
• −Забывают, что собственный тип на базе числа тоже требует явной конверсии.
• −Называют версию 1.21 для slices.Sorted и maps.Keys - итераторы приехали в 1.23.