Во-вторых чтобы реализовать верифицируемую эволюцию схемы.
Схемы очень часто изменяются с выходом новых версий программы. Общающиеся программы обновляются не синхронно и надо как-то им уметь продолжать общение несмотря на то что у кого-то схема новее, у кого-то древнее. Так же сохраненные данные могут быть старой версии.
Для этого схемы должны обладать совместимостью. Совместимость бывает прямой и обратной, давайте рассмотрим оба случая.

Обратная совместимость означает, что данные сериализованные старой версией схемы могут быть десериализованны новой версией.
Прямая совместимость означает, что данные сериализованные с новой версией схемы могут быть десериализованны старой версией.

Как такое возможно? Десериализатор должен узнать какая версия схемы у данных, либо снаружи, либо из данных. А так же должна быть стратегия того, как конвертировать данные, например какое значение новым полям указать.
Это уже сразу несколько вариантов. Alkahest точно будет поддерживать вариант с указанием версии снаружи и указанием версии прямо в данных.
Но скорее всего не будет варианта с указанием в данных версии для субструктур, всё дерево схемы будет с одной версией.

С прямой совместимостью есть еще вариант без указания версии. Если новая версия строго шире старой, то десериализатор со старой схемой просто игнорирует хвост.
Тут помогает сериализация с указателем, потому что размер поля указателя фиксированный, так что схема может обладать прямой совместимостью и не влиять на схему, полем которой она является, если используется указатель.

То есть если было:

formula A = { ... }
formula B = { ... }

formula Foo = {
  a: A,
  b: B,
};

formula Bar = {
  a: &A,
  b: &B,
};

То старая формула Foo не будет совместимой с новой версией, если A расширилось, а Bar будет.


Что тут будет делать Alkahest? Проверять совместимость! Автор схемы указывает вид совместимости, а функция верификации убедится, что новая схема обладает указанной совместимостью со старой схемой.
Ультой будет проверка диффа кода на наличие несовместимых изменений схемы. И GitHub Action для запуска этой проверки в PR.

Интересным образом оказывается, что не так уж сложно сериализовывать Option<!> в 0 байт.

Без специализации и special-casing-а.
Просто дискриминанты с uninhabited схемами не считаются.
А значит у Option<!> только 1 дискриминант None. Значит надо 0 байт на него, и на его тело тоже 0 байт.

Еще одно очевидное свойство ! типа и сериализации.

Его можно сериализовать в любую схему!
В самом деле, если мы сериализуем значение !, то как известно этот код недостижим. А значит не важно, какая там схема.
На практике ! будет у варианта `enum`а, который невозможен. Значит сериализовываться будет всегда какой-то другой вариант или вообще не будет.

А вот десериализовывать ! можно только из схемы !.
Потому что эта схема не имеет представления в данных.
На практике ! будет у варианта схемы enum`а, которому дискриминант не назначен вовсе, а значит какие бы ни были данные, а функция десериализации ! не будет вызвана.

Загадка про Rust

Что происходит с атрибутом #[cold] над const функцией, когда её вызов вычисляется еще до LLVM?

#[cold]
const fn mark_cold() {}

if condition {
  mark_cold();
  // Это холодный бранч или нет?
}

Мой друг сказал, что код на расте сложно читать.

Ну что тут сложного?

Пишу тесты.
В прошлый раз у меня ушла уйма времени на отладку процесса сериализации и десериализации.

В этот раз минорный неточности, но в основном все сразу работает.
Чаще ошибка в тесте, а не в библиотеке.

О как.
Оказывается буквально 22 января в стейбл приехали новые методы для слайсов.
<[MaybeUninit<T>]>::assume_init_* семейство, меньше трансмутить. Трансмутить можно, но всегда опасное.
<[T]>::as_array и компания - ура, минус причина писать unsafe.

Когда разозлился, что твоего другана завалили при посадке