Модуль 5 ⏱ ~25 мин чтения 📐 1 Mermaid диаграмм

8. Операторы и выражения

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

Создатели Go придерживаются прямо противоположного взгляда: виртуозность выражения не должна приносить в жертву понятность кода. В кодовой базе, которую поддерживают десятки инженеров на протяжении десятилетий, «произведение искусства» в коде — это синоним «нечитаемого мусора».

Язык Go намеренно ограничивает комбинаторику выражений. Здесь нет перегрузки операторов, инкремент выведен из класса выражений, а побитовые операции очищены от исторического мусора Bell Labs сорокалетней давности. В этой статье мы разберем механику операторов в Go, выясним, как компилятор оптимизирует логические цепочки для конвейера процессора, и познакомимся с уникальными битовыми операциями языка.

1. Инкремент и декремент: Конец неопределенному поведению

В C, C++ и Java операции инкремента (++) и декремента (--) являются выражениями (expressions). Выражение обязано вычисляться в значение. Из-за этого программисты десятилетиями соревновались в написании загадок вроде:

// Источник ночных кошмаров в C/C++:
i = i++ + ++i;

Исторически такие конструкции порождали сложнейшие баги. В C и C++ (до C++17) это выражение — Неопределенное Поведение (Undefined Behavior): одна и та же переменная меняется дважды без точки следования, а порядок вычисления операндов не фиксируется стандартом и зависит от оптимизаций конкретного компилятора. (Выражение с разными переменными, вроде a = b++ + ++c, в C неопределённым не является — лишь порядок вычисления не задан. В Java порядок слева направо задан спецификацией, и даже i = i++ + ++i определено — но читается с трудом.)

Ловушка / Gotcha

В Go ++ и -- — это инструкции (statements), а не выражения. Они не возвращают значение.

i := 0
// j := i++ // Ошибка компиляции! syntax error: unexpected ++
i++         // Правильно: отдельная инструкция

Кроме того, в Go не существует префиксных форм ++i или --i. Есть только постфиксная запись, которая применяется к операнду на отдельной строке.

Это лаконичное архитектурное решение создателей Go полностью уничтожило целый класс коварных ошибок, связанных с порядком вычислений (Order of Evaluation). Код стал чуточку длиннее, но абсолютно предсказуемым.

2. Битовые операции и уникальный &^ (Bit Clear)

Для бэкенд-инженера, проектирующего сетевые бинарные протоколы, работающего с правами доступа (битовыми масками) или криптографией, битовая арифметика — это хлеб насущный. Go предоставляет полный арсенал низкоуровневых операторов: & (AND), | (OR), ^ (XOR), << (сдвиг влево), >> (сдвиг вправо).

Но здесь есть два фундаментальных отличия от традиционных языков C-семейства.

Унарный XOR вместо побитового NOT (~)

В C и C++ для побитового отрицания (инвертирования всех битов) используется символ тильды ~. В Go тильды нет. Ее роль берет на себя унарный оператор ^ (XOR с маской из единиц):

var a uint8 = 0b00001111
b := ^a // Результат: 11110000

Правило тривиально:

Если ^ стоит между двумя операндами (a ^ b) — это бинарный исключающий ИЛИ (XOR).
Если ^ стоит перед одним операндом (^a) — это унарная побитовая инверсия.

Уникальный оператор: &^ (Сброс бита / AND NOT)

В Go включен уникальный оператор &^, который читается как «AND NOT» (побитовое И-НЕ, или Bit Clear). Он предназначен для прицельной очистки (сброса в ноль) выбранных битов по маске.

Выражение z = x &^ y работает по правилу: каждый бит в z будет равен 0, если соответствующий бит в y равен 1. Если же в y стоит 0, то бит берется из x без изменений.

const (
    Read    = 1 << iota // 001
    Write               // 010
    Execute             // 100
)

func main() {
    permissions := Read | Write | Execute // 111 (Все права)

    // Хотим отобрать право Write
    // В C++ пришлось бы писать: permissions &= ~Write
    // В Go есть элегантный оператор сброса:
    permissions = permissions &^ Write // 101 (Остались Read и Execute)
}

Под капотом: Mechanical Sympathy

На аппаратном уровне оператор &^ во многих микропроцессорных архитектурах транслируется в одну нативную ассемблерную инструкцию. Например, в архитектуре ARM64 есть специализированная инструкция BIC (Bit Clear), выполняющая логическое И с предварительно инвертированным вторым операндом за 1 такт CPU. Компилятор Go преобразует конструкцию a &^ b напрямую в инструкцию BIC a, b, экономя регистры и такты процессора на предварительное создание инвертированной маски. На amd64 одна инструкция ANDN получается только при GOAMD64=v3 (иначе — пара NOT + AND).

Арифметические сдвиги и тип результата

Операторы сдвига << и >> сдвигают разряды числа. Однако семантика сдвига вправо (>>) строго привязана к типу левого операнда:

Логический сдвиг (Logical Shift): Если операнд беззнаковый (uint, uint64), старшие биты гарантированно заполняются нулями.
Арифметический сдвиг (Arithmetic Shift): Если операнд знаковый (int, int64), старшие освобождающиеся биты дублируют знаковый (старший) бит, сохраняя знак отрицательного числа. Это деление на степень двойки с округлением вниз: -7 >> 1 == -4, тогда как -7 / 2 == -3 (оператор / округляет к нулю, а знак остатка % следует за делимым: -7 % 3 == -1).

var x int8 = -128 // 10000000 в дополнительном коде
fmt.Printf("%b\n", uint8(x)) // 10000000

// Арифметический сдвиг знакового типа сохраняет знак (единицы слева)
fmt.Printf("%b\n", uint8(x>>1)) // 11000000 (биты числа -64)
fmt.Printf("%b\n", x>>1)        // -1000000 (%b для знакового печатает знак и модуль)

3. Short-Circuit Evaluation (Ленивые логические вычисления)

Логические операторы && (И) и || (ИЛИ) в Go вычисляются строго слева направо по принципу «короткого замыкания» (Short-circuit evaluation). Правый операнд гарантированно не вычисляется, если результат всего составного выражения уже однозначно определен левым операндом:

// Если cache == nil, паники не будет, так как cache.Get() даже не попытается выполниться.
if cache != nil && cache.Get("key") == "found" {
    // ...
}

Mechanical Sympathy: Оптимизация ветвлений

На уровне микроархитектуры ленивые вычисления — это фундаментальный инструмент управления потоком команд (Control Flow), оказывающий прямое влияние на предсказатель переходов (Branch Predictor) и конвейер процессора:

flowchart TD
    classDef process  fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef success  fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc
    classDef error    fill:#7f1d1d,stroke:#f87171,stroke-width:1px,color:#f8fafc
    classDef warning  fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef entry    fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef aux      fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc
    classDef system   fill:#312e81,stroke:#a78bfa,stroke-width:1px,color:#f8fafc
    classDef data     fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc
    classDef network  fill:#881337,stroke:#fb7185,stroke-width:1px,color:#f8fafc
    classDef accent   fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    EvalA["Проверка cache не равно nil"]:::warning --> CheckA{"cache не равно nil?"}
    CheckA -->|"Да"| EvalB["Вызов cache.Get"]
    CheckA -->|"Нет"| FalseBranch["Пропуск тела if"]
    EvalB --> CheckB{"Результат равен found?"}
    CheckB -->|"Да"| TrueBranch["Выполнение тела if"]
    CheckB -->|"Нет"| FalseBranch

Компилятор превращает оператор && в цепочку машинных условных переходов (JMP / JNE в x86 ASM). Правое условие может содержать вызов функции с обращением к сети или тяжелые математические расчеты. Грамотное структурирование проверок спасает миллионы тактов CPU.

4. Приоритет операторов: Минимализм Go

Одной из причин появления багов в коде на C и C++ является перегруженная таблица приоритетов, насчитывающая свыше 15 уровней. Разработчикам приходится мучительно вспоминать, связывает ли оператор побитового сдвига << сильнее, чем проверка на равенство ==, и почему побитовые & и | обладают более низким приоритетом, чем операции сравнения (известная историческая ошибка раннего дизайна C).

Создатели Go безжалостно реорганизовали приоритеты, сократив их до предельно прозрачных 5 уровней (чем выше уровень, тем выше приоритет вычисления):

*, /, %, <<, >>, &, &^ (Умножения, деления, остатки, сдвиги и побитовые И / сброс)
+, -, |, ^ (Сложения, вычитания, побитовые ИЛИ / исключающие ИЛИ)
==, !=, <, <=, >, >= (Сравнения)
&& (Логическое И)
|| (Логическое ИЛИ)

Благодаря тому, что побитовые операции (&, |, ^) встали в один уровень с арифметическими (* и +), выражения вида if a & mask == 0 в Go работают без лишних скобок и абсолютно логично. В C/C++ это же выражение трактуется как a & (mask == 0), что приводило к катастрофическим скрытым дефектам в проверках масок.

5. Никакой перегрузки операторов

В языке Go принципиально отсутствует возможность перегрузки операторов (Operator Overloading). Вы не можете переопределить +, чтобы складывать математические структуры Matrix или Vector.

Вместо этого вы объявляете обычный метод:

func (m Matrix) Add(other Matrix) Matrix

Почему принято такое радикальное решение? Авторы языка исходили из того, что за базовым оператором языка не должен скрываться вызов пользовательского кода с его скрытыми побочными эффектами.

В C++ выражение a = b + c может скрывать внутри блокировку системного мьютекса, чтение файла с диска или выделение сотен мегабайт памяти в куче.
В Go при взгляде на строку a = b + c вы на 100% уверены: здесь происходит либо сложение чисел в регистрах процессора, либо конкатенация строк, которая выделяет память под результат и копирует оба операнда (O(n); runtime.concatstrings). Никакого пользовательского кода, сетевых вызовов или блокировок за оператором не скрывается. (Сравнение == строк и массивов тоже стоит O(n).)

Ловушка / Gotcha: Деление и %

Оператор вычисления остатка % (modulo) в Go определен исключительно для целочисленных типов. Если вам необходимо вычислить остаток от деления для вещественного float64, вы обязаны воспользоваться функцией math.Mod(a, b).
Деление константы на константный ноль (например, x := 1 / 0) пресекается компилятором на этапе сборки. Однако если делитель является переменной (1 / y, где y = 0), сработает проверка делителя, которую компилятор заранее вставил перед инструкцией деления: рантайм вызовет панику integer divide by zero (до аппаратного исключения SIGFPE дело не доходит). Не перехваченная recover, эта паника завершает весь процесс с кодом 2, а не только текущую горутину (подробности обработки паник мы разберем в лекции 13. Panic, Recover и stack trace).
Деление вещественных чисел на ноль паники не вызывает: результат — +Inf, -Inf или NaN.

Итог

Инкремент ++ и декремент -- являются обособленными инструкциями, а не выражениями. Они не возвращают значений и не могут быть встроены в другие конструкции.
Для побитовой инверсии используется унарный ^ вместо символа ~.
Оператор &^ (AND NOT) — специализированный инструмент для сброса битов, нативно мапящийся во многих архитектурах в инструкцию вроде ARM64 BIC.
Логические операторы && и || вычисляются лениво (short-circuit). Грамотный порядок условий экономит такты процессора.
Таблица приоритетов упрощена до 5 уровней, устраняя классические ловушки языка C при работе с битовыми масками.
Отсутствие перегрузки операторов гарантирует предсказуемость исполнения: за оператором не скрывается пользовательский код и его побочные эффекты.

Операторы в Go предельно честны: они выполняют именно то, что записано в коде, не усложняя ментальную модель инженера. Сформировав представление о данных и операциях над ними, мы логично подходим к механизмам ветвления и повторения. В следующей лекции — 9. Управляющие конструкции. if, switch, for — мы исследуем, как Go обходится единственным циклом for, отказавшись от избыточных while и do...while, и почему конструкция switch в Go превосходит аналоги в большинстве языков.