Нужно ваше мнение: на каких новых фичах LEWG (библиотечный комитет

по стандартизации C++) должен сосредоточить своё внимание чтобы протолкнуть в C++23?

Сейчас комитет почти закончил разгребать баги C++20, осталось 8 двухчасовых собраний до feature freeze. Networking и модуляризация стандартной библиотеки не поспевают к C++23.

Если никто не возражает, я бы скромно попросил std::embed.

Мне тоже нравится эта идея, поэтому поддержу

Поддерживаю(мне кажется, тут станет мало места, если все поддерживающие выскажутся ;))

А нетворкинг точно не поспевает?

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

P1061R0: Structured Bindings can introduce a Pack (by Barry Revzin, Jonathan Wakely) (2018-05-01) (Related: GitHub issue) P1061R1: Structured Bindings can introduce a Pack (by Barry Revzin, Jonathan Wakely) (2019-10-07) (Related: GitHub issue)

Ну, может конечно случиться чудо... но врядли за 16 часов

И ещё хотелось бы подвижек с monadic expected/optional, но чтобы получить хороший результат, нам нужны улучшения в Core. Собственно, то же самое и с std::embed, это снова с высокой вероятностью языковая фича в библиотеке, поэтому моё мнение – в общем хочется больше тщательной работы с Core и меньше получать результатов вроде std::initializer_list Честно сказать, мне кажется, что когда одновременно релизятся связанные изменения в языке и библиотеке – это становится проблемой в будущем и я даже рад, что языковые корутины получили возможность обкатки перед тем, как они попадут в библиотеку Меня здесь проклянут за эту идею, но лично мне хотелось бы чаще видеть именно такой процесс внедрения фич

А длинная арифметика там как? Не светит ?

Светит... в C23 почти приняли аналог wide_int

Вот, это бы и добить...

Я бы попросил libwinkrnlc++ тогда (или по крайней мере стандартизацию CRT)

А можно список, из чего выбрать?)

Поддерживаю, было бы здорово ознакомиться.

Довести ranges до состояния когда ими можно будет пользоваться из коробки.

А с mdspan там как ? Над чем сейчас вообще работает Lelbach ?

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/ И немного отсюда http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/

Там core работает над operator[](int, int, int, int) С его помощью можно mdspan улучшить. Хз что по срокам

Это вы про это http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2128r2.pdf ?

Как уже сказали выше, по-максимуму облагородить ranges, из того что еще до LWG не доехало, а в LEWG болтается, меня больше всего https://wg21.link/p2164 интересует. И https://wg21.link/p2168.

У нас с @oficsu возникло некоторое обсуждение контрактов. В частности того, что делать если функция помечена как небросающая, но нарушает предусловие. Не знаю точно как планировал стандарт, бросает ли исключение нарушение предусловия, но стандарт уже содержит ошибку на данный счёт: https://eel.is/c++draft/dcl.attr.noreturn#example-1 По сути, из этого выходит, что нарушение контракта является UB. Хорошо бы это поправить

Уточню С моей точки зрения, этот вопрос не касается контрактов, а лишь только атрибутов и дальше речь только о ссылке из сообщения выше на стандарт и атрибутах Насколько я помню, атрибуты не должны менять наблюдаемое поведение. В моей ментальной модели, сломанный вплоть до UB код из-за появления атрибута без изменения кода – это вполне наблюдаемое поведение и кажется, что так не должно быть

С моей же точки зрения атрибуты контрактов в любом случае меняют наблюдаемое поведение. Этот же атрибут суть есть контракт, в данном случае(указанном выше) он выражает предусловие, нарушение которого UB.

Также, некоторое время назад, я обнаружил ещё один баг в стандарте: https://eel.is/c++draft/basic.def.odr#16 Это было введено здесь: https://wg21.cmeerw.net/cwg/issue2300 В попытке пофиксить лямбды и ODR. Но это неудачная попытка, хотя бы потому, что приведённый выше пример из стандарта уже невалиден, т.к. https://eel.is/c++draft/dcl.fct.default#4.sentence-6 действует как на g, так и на h, являющуюся inline. И боюсь этот момент в стандарте не поправить просто объявлением h ifndr, т.к. цели этого исправления в принципе были другими, вероятно. Возможно, @Endill, который исследовал этот вопрос глубже меня, захочет что-то добавить

А корутины в std?

> сломанный вплоть до UB код из-за появления атрибута без изменения кода – это вполне наблюдаемое поведение и кажется, что так не должно быть Так уже происходит с существующими аттрибутами

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

Вы имеете в виду что-то конкретное, может быть какой-то из существующих proposal-ов? Потому что кажется, что для начала нужна какая-то модель async programming в целом (что-то вроде злосчастных executors), а ничего близкого к общепринятому в C++ пока нет.

я имею в виду в качестве примера синтаксис лябмд, которые есть синтаксический сахар поверх "ручных" функциональных объектов

Аналог tl::expected не смогут принести? Вроде бы даже proposal от автора библиотеки был

А зачем? Там один хедер, подключай его

Говорят надо сначала pass overload sets to callables, что поломает ABI.

давайте сеть это нужно многим

Ну да, аттиибуты не должны влиять на поведение программ. Но увы - влияют. Кажется что тут поздно что-то чинить

Всем спасибо за фидбек, вот так в итоге получилось LEWG распланировать встречи https://github.com/cplusplus/LEWG/wiki/2021-Telecons Монадические интерфейсы для optional и ranges::to уже отправили в LWG.

А пожелания забить на все и успеть executors + networking принимаются?) Или это совсем не реалистично? Upd: понятно, печально

а к ним можно присоединиться как слушателю?

не завезут в ближайшие пару лет? печаль беда

Присоединяйся к разработке yaclib)0)

чта?

https://github.com/YACLib/YACLib пишу свой велосипед

Увы, нет, если вы не автор proposal

А сети в с++ 23 не будет?

Офигенно, и executors и mdspan среди топиков

В понедельник послушаю встречу, расскажу

Если можно, расскажите что с ними всё же :) Или это было про следующий понедельник?