Исправление ox55ff, (текущая версия) :
потому к нему нет таких претензий
range for это сахар. Ты утверждал, что сахару в языке не место. А теперь выясняется, что ты трескаешь сгущёнку под одеялом.
Как мне добавить поддержку кастомных типов?
Это зависит от того как сделать поддержку интерполяции в ядре языка. Мне в голову пришёл следующий способ.
У нас есть пользовательские литералы.
OutputType operator "" _suffix(const char* str, size_t size);
// После чего можно писать
"abc"_suffix
// И будет вызван соответствующий оператор
Можно сделать похожий синтаксис для интерполяции:
std::string operator $"" _fmt(const char* str, Args&&... args)
{
// Вызов классического форматера
return fmt::format(str, std::forward<Args>(args)...);
}
// Использование
std::string str = $"a = {a}, b = {b}"_fmt;
// Что компилятором развернётся в вызов оператора
std::string str = $""_fmt("a = {}, b = {}", a, b);
От ядра языка нужно чтобы он смог выдернуть имена переменных и передать их в виде списка аргументов в оператор интерполяции. Остальным займутся библиотеки.
Я не хочу std::string. Я хочу std::pmr::string. Я хочу std::wstring.
Пишешь соответствующий оператор с другим суффиксом, который возвращает нужный тебе тип. Для std::string будет реализация из коробки в stdlib.
Не ври. Вот ссылка, сверху еще немного претензий.
Нет там претензий. Вопросы вида «а что там с лайфтаймами» не катят. Приводи пример в котором есть проблемы с лайфтаймами и обязательно пример в котором этих проблем нет при использовании классического форматера. Мы же сравниваем два подхода. Не хочу тратить время на догадки о какой проблеме ты говоришь.
Зачем в ядро языка добавлять ущербанство
Затем, что все библиотеки для форматирования будут говном и ущербанством пока в ядре языка не появится интерполяция строк. И только с её появлением эти библиотеки смогут сделать удобную реализацию.
co_coco и co_keyword
А ты сначала придумай что ещё может понадобится кроме yield и return. Это стандартные операторы и очевидно они должны иметь удобный способ вызова.
Исходная версия ox55ff, :
потому к нему нет таких претензий
range for это сахар. Ты утверждал, что сахару в языке не место. А теперь выясняется, что ты трескаешь сгущёнку под одеялом.
Как мне добавить поддержку кастомных типов?
Это зависит от того как сделать поддержку интерполяции в ядре языка. Мне в голову пришёл следующий способ.
У нас есть пользовательские литералы.
OutputType operator "" _suffix(const char* str, size_t size);
// После чего можно писать
"abc"_suffix
// И будет вызван соответствующий оператор
Можно сделать похожий синтаксис для интерполяции:
std::string operator $"" _fmt(const char* str, Args&&... args)
{
// Вызов классического форматера
return fmt::format(str, std::forward<Args>(args)...);
}
// Использование
std::string str = $"a = {a}, b = {b}"_fmt;
// Что компилятором развернётся в вызов оператора
std::string str = $""_fmt("a = {}, b = {}", a, b);
От ядра языка нужно чтобы он смог выдернуть имена переменных и передать их в виде списка аргументов в оператор интерполяции. Остальным займутся библиотеки.
Я не хочу std::string. Я хочу std::pmr::string. Я хочу std::wstring.
Пишешь соответствующий оператор с другим суффиксом, который возвращает нужный тебе тип. Для std::string будет реализация из коробки в stdlib.
Не ври. Вот ссылка, сверху еще немного претензий.
Нет там претензий. Вопросы вида «а что там с лайфтаймами» не катят. Приводи пример в котором есть проблемы с лайфтаймами и обязательно пример в котором этих проблем нет при использовании классического форматера. Мы же сравниваем два подхода. Не хочу тратить время на догадки о какой проблеме ты говоришь.
Зачем в ядро языка добавлять ущербанство
Затем, что все библиотеки для форматирования будут говном и ущербанством пока в ядре языка не появится интерполяция строк. И только с её появлением эти библиотеки смогут сделать удобную реализацию.
co_coco и co_keyword
А ты сначала придумаю что ещё может понадобится кроме yield и return. Это стандартные операторы и очевидно они должны иметь удобный способ вызова.