Вопрос удобства, для чисел например куча опций формата - база, выравнивание, ширина и т.п. Или то же время, много составляющих, нереально без спецификации описать все возможные форматы операциями. Но иногда нужен custom и это удобней делать через новые типы (которые тоже могут какие то спецификации поддерживать). Я ж не могу например для size_t переопределить способы форматирования, но могу завернуть его в новый тип, format("file size: {}", fmt::bytes(size)).

> Я ж не могу
это ключевая подстрока, это ситуация двойного диспетчера (формат, тип), и у тебя этот диспетчер гвоздями вбит со стороны "тип"

Не у меня, всё из питона растет :)

> нереально без спецификации описать все возможные форматы операциями
почему нереально? d2s(1488, "%.3") уже решило этот вопрос

осталось только разобраться, как это без строки записать

А, объединить спецификацию со ссылкой на значение. Ну можно, но многословно.

Так ты это и делаешь

>  fmt::bytes(size)
вот же она, положила

надо просто перейти на следующий уровень
format("time stamp: {}", fmt::time(tp))

А что мешает быть форматтеру структурой с operator (), которую вызывает сам std::format?

format("integer: {}", fmt::decimal(n))

Для подстановки

Так он и есть такая структура.

Ну я ж говорю, можно, но многословно. Если эти же настройки можно записать символами внутри спецификации, будет просто короче.

Лишних аллокаций немного будет наверное правда тогда надо убедиться, что форматируемое значение не сгинуло никуда

То есть хорошо писать {bytes}, но не можем, потому что fmtlib, верно?

Потому что если строку формата таки разобрать, вызов будет query_back_inserter(bytes_tag, int)

для format("file size: {bytes}", 1488)

Да не, ничего хорошего. У чисел и так сложная спецификация, куда там вписать bytes? Если говорить о регистрации custom обработчиков... Ну дорого же, а конфликты?

А нет конфликтов, ты не можешь менять спецификацию того, что описано в std::format, как и сейчас