забавный момент, тут один инженер немного перемудрил, реализовывал апишку к SSE через LLVM. апишка требовала вторым аргументом Imm (константу) но он решил дать возможность вводить туда и неконстанту при помощи кодогенерации свитча -_- https://gist.github.com/EgorBo/ea3f749413d573f5f1d4a522ff7cf841 :D

Это всё уже продумано. В начале файла в единственном экземпляре очень компактно хранится информация о типах и всех структурах данных, либо указание имени внешнего модуля, в котором их нужно искать - то есть сам пользователь может сделать выбор, хранить схему в самом файле или отдельно. Дальше идёт несколько байт, которые говорят, что далее идёт экземпляр описанной структуры, после чего идут сырые и компактные данные без каких-либо метаданных внутри, упакованные в соответствии указанным типом.
Мой формат определён как в текстовом, так и в бинарном виде. Любой текст можно взаимно однозначно (плюс-минус форматирование и синтаксический сахар) перегнать в бинарный вариант и наоборот. Нужна человекочитаемость - конвертим в текст и работаем с ним. Нужна бинарность, компактность и скорость обработки - перегоняем в бинарь.

В общем, пользователь контролирует абсолютно всё, что хочет.

это вы тут что обсуждаете?

Псилоцибы

кто сказал грибы?

Ты можешь контролировать всё. Допустим, файл должен содержать два массива. Первый - массив чисел, второй - их квадратов.
Можешь хранить массив чисел (поле Numbers) и сделать виртуальное поле квадратов этих чисел NumbersSqr := Numbers.@map[:[x] {x*x}].
Можно наоборот хранить квадраты чисел и виртуальное поле, которое считает их корень.
А можно хранить и то и другое в виде данных, введя избыточность.
При этом, программе, которая с этими полями работает, всё равно, виртуальные они или реальные. Она просто обращается к Numbers или NumbersSqr. Тот, кто создаёт файл, решает, как он хранится.

О, увидел грибы, зашёл

Здрасте товарищь майор

Но при этом ты говоришь что вычисляемые поля это уже грубо говоря вторая стадия

А первая - та что убивает технологии - какая?

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

Без вычисляемых полей это БД. Зачем мне эта БД если есть куча других в которых я могу разобраться прочитав документацию, а не надеясь найти человека который придумал 'свой формат'

Похоже на View в SQL, только куча шумных спецсимволов. То же самое можно было бы записать как NumbersSqr = Numbers.Map(x => x*x) ?

Напиши в телегу тимлиду

Я теья умоляю, я с инженерами майкрософта в телеге переписываюсь и все ок

Не так уж это и тяжело

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

Или вон обратись к Егору и затолкай мелкософту

Ну да, в начале их не будет, как и любых других возможностей обрабатывать данные средствами языка. Первая стадия - это чисто формат сериализации и хранения, а обработкой занимается приложение.
На первой стадии рантайм умеет конвертить между LE/BE, полями разной битности, float <-> int. Можно создать алиасы для переименованных полей для обратной совместимости.
Этого достаточно, чтобы убить существующие технологии.

Желаю удачи с хранением, к примеру, массивов 3-битных параметров в БД и передачей БД между клиентами и серверами.
Кстати, забыл упомянуть, что мой формат неплохо в потоковом режиме работает. Сервер присылает клиенту схему протокола, а клиент неважно какой он версии будет конвертить свои запросы и, в соответствии, с этой схемой присылать серверу. Таким образом, решится проблема обновления всех клиентов при обратно несовместимых изменениях протокола между сервером и клиентом.