Яндекс выложил в опенсорс YDB

а userver тоже в этом году выйдет в опенсорс?

Да, если не случится непредвиденного. Выложим в opensource вместе с:

• Шаблоном для создания своих сервисов. CI, сборка, тестовое окружение уже настроены из коробки

• Сервисом динамических конфигов. Можно менять параметры вашего работающего сервиса без его рестарта

• Документацией, примерами и чатами поддержки (куда же без этого!)

С++23 — итоги февральской встречи международного комитета

Нравится потому что понятнее чем альтернативы:

  inspect (shape) {
    (as<Circle>    ? [r])   : return 3.14 * r * r;
    (as<Rectangle> ? [w, h]): return w * h;
  } 

Хотя, на мой взгляд, с as/is тоже не идельно:

inspect (shape) {
  [r]   as Circle    => 3.14 * r * r;
  [w,h] as Rectangle => w * h;
}

С++23 — итоги февральской встречи международного комитета

Ок, уговорили. Если сделаете черновое предложение по инструкции - поможем с его доведением до ума и продвижением в комитете

С++23 — итоги февральской встречи международного комитета

Работы ведутся только на уровне отдельных тулчейнов/компиляторов. В стандарт пока рано включать - это не самая популярная фича и есть проблемы с диагностикой

С++23 — итоги февральской встречи международного комитета

А давайте действительно пофорсим фикс через коментарий от страны. В предложении есть замечание, что возможна кастомизация выкидывания исключения, но в данный момент её не предлагают.

Завёл тикет https://github.com/cpp-ru/ideas/issues/509

Добавьте плиз в тикет примеров/мотивации/деталей/...

С++23 — итоги февральской встречи международного комитета

Да, там может быть что угодно, хоть std::vector

С++23 — итоги февральской встречи международного комитета

Вот так:

const auto helloWorld = container
    | std::views::join_with(", ")
    | std::ranges::to<std::string>()
  ;

С++23 — итоги февральской встречи международного комитета

Это было основным кейсом у Александреску. Однако большинство людей в комитете весьма обоснованно решили, что:

• кидать int/enum -- жуть и будет проскакивать мимо всех пользовательских catch(const std::exception& e)

• обязывать пользователей всегда хранить тип, отнаследованный от std::exception -- повлияет на производительность std::expected, из-за vptr+код+флаг он перестанет влезать в регистры для возврата и компилятор начнёт возвращать его через стек

Если вы видите рабочий выход из этой ситуации -- предлагайте рабочее решение, отправим его замечанием к C++23 от России.

С++23 — итоги февральской встречи международного комитета

std::views ленивые и не делают промежуточных контейнеров. Так что и std::views::chunk, и std::views::zip, и std::views::take лишь ловко оперируют указателями и возвращают вам ссылки на нужные элементы в нужный момент.

С++23 — итоги февральской встречи международного комитета

Боюсь что придётся вначале стандартизировать asm: http://eel.is/c++draft/dcl.asm

С++23 — итоги февральской встречи международного комитета

К предложению есть серьёзные возражения https://wg21.link/p1947r0 и много вопросов по поводу расширяемости на пользовательские типы. Пока проблемы не будут решены - предложение не пройдёт... после этого может тоже не пройти. К тому же один из разработчиков executors планировал сделать заход на исключения, может придумает что-то кардинально лучшее.

С++23 — итоги февральской встречи международного комитета

Завезут, но в C++23 не успели.

До тех пор придётся пользоваться заменами, на подобие https://github.com/graphitemaster/incbin

С++23 — итоги февральской встречи международного комитета

Не, вроде такое не планируется :)

Теперь можно получится продвинуть бумагу на constexpr для <cstring>. А то как-то неправильно писать std::string_view{s}.size() вместо std::strlen(s)

С++23 — итоги февральской встречи международного комитета

Да, ranges ленивые и я походу тоже: в коменте справа я написал, что мы получим если пройдёмся по всем элементам диапазона и сохраним их куда-нибудь.

С++23 — итоги февральской встречи международного комитета

В примере везде используется std::get, который кидает исключение при попытке достать неверный тип. Замена на get_unsafe кардинально изменит поведение типа

С++23 — итоги февральской встречи международного комитета

В стандарте прописывается интерфнйс а не реализация. Слова "exposition only" в предложении не спроста стоят. Так что ничего не запрещает оптимизацию из abseil использовать в реализации стандартной библиотеки.

С++23 — итоги февральской встречи международного комитета

На operator*() никак std::variant не ложится, а std::visit покрывает большинство кейсов когда нужен непроверенный доступ. Если у вас другие кейсы и непровереный доступ вам нужен - пишите предложение для включения в стандарт, поможем с защитой идеи.

С++23 — итоги февральской встречи международного комитета

В комитете есть ребята из гугла, но они не торопятся предлагать подобное, а вместо этого голосуют по предложению expected. Может Status и StatusOr не так ужи и хороши?

С++23 — итоги февральской встречи международного комитета

Они базируются на рефлексии, а рефлексия окажется в лучшем случае в C++26. Так что пока ожидаем

С++23 — итоги февральской встречи международного комитета

Плохая поддержка в компиляторах - основной стоппер. Тот же Boost пока не внедрил модули, в частности потому что у большинства разработчиков на их машинах в компиляторах модули просто не работают.