Как работают дженерики в C# под капотом?

Давай разберём, как эта штука с дженериками в C# под капотом работает, а то некоторые думают, что это просто магия какая-то. Нет, блядь, там всё продумано до безобразия, просто мозг иногда ебётся, когда пытаешься понять.

Вот смотри, главный прикол в том, что информация о типе, который ты туда засунул, не стирается после компиляции, как в некоторых других языках. Это называется реификация. То есть в рантайме система всё ещё знает, что у тебя List<int>, а не просто какой-то List<T>. Это позволяет делать проверки типов, касты и прочую хуйню прямо во время выполнения.

Как это происходит, по шагам:

1. Ты пишешь код на C# и компилируешь. Компилятор смотрит на твой List<T> и выдаёт на выходе обобщённый IL-код (это такой промежуточный язык). В этом IL-коде есть метаданные, где написано: "эй, тут есть параметр T, запомните это".
2. Программа запускается, и в дело вступает JIT-компилятор. Вот тут самое интересное. JIT — это тот пацан, который переводит IL в настоящий машинный код. И он не дурак. Когда он впервые видит, что ты создаёшь, например, List<int>, он создаёт на лету специализированный машинный код именно для int. Не абстрактный, а конкретный, где int — это 4 байта, с ними можно работать напрямую.

А теперь лайфхак от CLR, чтобы не ебать себе мозг и память:

• Для всех ссылочных типов (классы) используется ОДНА И ТА ЖЕ скомпилированная реализация. Ну логично же, ёпта! List<string>, List<MyClass>, List<object> — под капотом это всё указатели, они одного размера (4 или 8 байт, смотря на архитектуре). Зачем плодить сущности? Сделали одну универсальную реализацию для работы с ссылками и юзают её для всех. Гениально и просто.
• А вот для каждого значимого типа (структуры, int, bool, decimal) JIT честно создаёт отдельную, заточенную под него версию. Потому что int — это 4 байта, long — 8, а decimal — вообще 16. И если бы использовали одну реализацию, пришлось бы всё время делать упаковку (boxing), а это, блядь, дикие накладные расходы. Так что для int — своя быстрая версия, для long — своя, и так далее.

Наглядный пример, чтобы въехать:

// Тут JIT создаст ДВЕ РАЗНЫХ реализации в памяти. Серьёзно.
var listOfInts = new List<int>();    // Спецверсия для 4-байтовых интов
var listOfLongs = new List<long>();  // Отдельная спецверсия для 8-байтовых лонгов

// А тут будет ОДНА реализация на всех. Экономно.
var listOfStrings = new List<string>(); // Общая кодовая база для ссылок
var listOfObjects = new List<object>(); // Та же самая кодовая база, просто тип другой

И зачем всё это, спросишь? Чем лучше старого доброго ArrayList?

• Типобезопасность. Компилятор тебя сразу нахуй пошлёт, если ты попытаешься запихнуть string в List<int>. С ArrayList же эта ошибка вылезет только в рантайме, когда у клиента на проде всё уже ебнулось.
• Скорость, блять! Для значимых типов — никакого боксинга. Всё летает. В том же ArrayList любой int при добавлении упаковывался в объект, а при извлечении — распаковывался. Сплошное издевательство над процессором и кучей.
• Код читать приятнее. Сразу видно, что за хлам в коллекции лежит. Не надо гадать.

Пару слов про подводные камни:

• Ограничения (where T : class) — это фишка для компилятора. Он на этапе компиляции по ним проверяет и подсказывает тебе. В рантайме они особой новой реализации не создают.
• default(T) работает именно потому, что JIT в момент компиляции знает точный тип T и может подставить 0 для int, null для string и т.д.
• Сделать T a + T b нельзя. Компилятор — не телепат, он не знает, есть ли у твоего типа T оператор сложения. Можно, конечно, через dynamic выкрутиться, но это будет медленно, как говно в проруби. Либо через выражения, но это уже для извращенцев.

Короче, система умная, всё для нас сделали. Остаётся только пользоваться и не выёбываться с необобщёнными коллекциями из каменного века.