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

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

Как такое возможно? Десериализатор должен узнать какая версия схемы у данных, либо снаружи, либо из данных. А так же должна быть стратегия того, как конвертировать данные, например какое значение новым полям указать.
Это уже сразу несколько вариантов. 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.

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

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

Спрашивал у ИИ на счёт квантовой теории. Оно мне между делом такое выдало:

Your body mass is mostly vibrating strong field energy.
Which is deeply unfair because you still have to exercise.

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

Жена:
Смотри, вот есть то и сё. Выбирай.
Я: Выбираю
Жена: Неправильно

Собрал быстренько на коленке такой вот виджет-тостер для отображения нотификаций.

В jkl уже сгромаздилось столько кода.

Кроме алгоритмов непосредственно для картинок, таких как алгоритмы блок-компрессии, обходы зигзагом, фильтры и конверторы разных цветовых схем.

Там образовались:
Векторы (те что из линала)
Враппер для io::Write, для записи бит, а не байт. Ну и враппер для io::Read, что бы эти биты читать.
Variable-length encoding для целочисленных. Три вида.
Алгоритмы компрессии общего назначения.

С трудом удерживаюсь что бы не вытащить всё по отдельным крейтам. У меня их и так слишком много 🫣

А начиналось то просто "ну чего тащить целый линал, если мне только Vec3 нужен..."
БАЦ! 2923 строки с кодом одних только векторов.

Или "хочу жать не байты, а значения"
БАЦ! lz77.rs, lz78.rs, lzw.rs, rle.rs, ans.rs

Или вот "в этом векторе чиселки то не такие уж огромные будут"
БАЦ! vle.rs, bits.rs

Остановите меня!