да, это верно

cheched exception, являющиеся возвращаемым значением функции

с типом "checked exception", который может быть параметром функции

сложности кстати будут в шаблонных функциях

там все идеально

у меня есть реализация

допустим мы хотим всё перебросить

и нужно как-то получить всё что мы перебрасываем

придётся немного дублировать код

ну если компилер научить выводить (а он может), все ок

и нужно как-то получить всё что мы перебрасываем

чтобы записать это в возвращаемый тип

using load_data_exceptions = type_base_set<...> using decode_exceptions = type_base_set<...> using load_string_exceptions = type_base_or<load_data_exceptions, decode_exceptions>

result<std::string, load_string_exceptions> load_string

using load_data_exceptions = type_base_set<...> using decode_exceptions = type_base_set<...> using load_string_exceptions = type_base_or<load_data_exceptions, decode_exceptions>

да, получается дублирование

да, получается дублирование

это не дублирование, просто тайпдеф

в совершенном шаблоне можно выводить через declval всегда

но это типичная проблема слишком шаблонного кода

ну допустим у нас в шаблонной функции принимаются 3 функтора и мы их все где-нибудь да вызываем в функции и получается нам нужно будет повторить все исключения этих функций в result type

exceptions_of_t<decltype(f1(args...)), decltype(f2(args2...)), decltype(f3(args3...))>

что-то в таком духе

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

-> exception_combine_t<ReturnTypes...>

auto parse(std::string s) -> variant_combine_t<ReturnTypes...> { if (...) { return float{/*...*/}; } else if (...) { return int{/*...*/}; } else { return s; } } соответственно возвращаемый тип будет std::variant<float, int, std::string> правда нужен какой-то адекватный синтаксис

exceptions_of_t<decltype(f1(args...)), decltype(f2(args2...)), decltype(f3(args3...))>

там можно auto

там можно auto

хммм, а это неплохая идея, если ты конечно про exceptions_of_t<auto>

-> exception_combine_t<ReturnTypes...>

если расширять синтаксис, там throws ( /*<condition> -> element или auto или typedef*/ auto, typedef exception_type )

или даже typedef throws(auto) exception_type

к сожалению, С++ не имеют воздействия на type deduction в auto

грубо говоря, auto в return не инстанцирует условный auto_common_type

auto parse(std::string s) -> variant_combine_t<ReturnTypes...> { if (...) { return float{/*...*/}; } else if (...) { return int{/*...*/}; } else { return s; } } соответственно возвращаемый тип будет std::variant<float, int, std::string> правда нужен какой-то адекватный синтаксис

variant_combine_t<auto> parse(std::string s) { /*...*/ }

variant_combine_t<auto> parse(std::string s) { /*...*/ }

да просто auto parse(std::string s) { /*спокойно выводим тип*/ }

да просто auto parse(std::string s) { /*спокойно выводим тип*/ }

но откуда компилятор узнает, что мы хотим std::variant?

но откуда компилятор узнает, что мы хотим std::variant?

ну мы там ручками выводим

using result_type = variant<какой-т>

using result_type = variant<какой-т>

ну вот, а я предлагаю для этого фичу новую

если речь про спецсинтаксис то я за void parse(std::string s) throws(auto)

если речь про спецсинтаксис то я за void parse(std::string s) throws(auto)

но я тут уже надумал не только для исключений)

но я тут уже надумал не только для исключений)

а, если про кастомизацию auto return type deduction, там сложно

например, непонятно, как работать с рекурсией

Чот на мой вопрос про RTTI для виртуального наследования в clang maillist за неделю никто не ответил :(

Попробуем stackoverflow https://stackoverflow.com/questions/52508052/rtti-for-virtual-inheritance-without-virtual-functions

видимо, в variant<auto> надо будет объяснять это variant<auto> кастомной выводилке

хотя если считать, что это монолитный оператор и поиск ведется именно variant<auto> мб сработает

например, непонятно, как работать с рекурсией

тут кажется её нельзя допускать вообще (я имею в виду напрямую return same_fun(...))

хотя если считать, что это монолитный оператор и поиск ведется именно variant<auto> мб сработает

т.е. инстанцируется специализация user_auto_deductor<variant<typename...>>

видимо, в variant<auto> надо будет объяснять это variant<auto> кастомной выводилке

в том случае с parse кстати прокатит и просто std::variant<auto> да, потому что я предполагаю, что вместо auto компилятор подставит все типы, которые попыталась вернуть функция

в случае с parse это float, int, std::string

вообще интересно если возвращаемое значение будет user_auto_deductor_t<variant<typename...»

что делать с рекурсией интересно

user_auto_deductor_unknown?

variant_combine_t<auto> parse(std::string s) { /*...*/ }

т.е. уже так std::variant<auto> parse(std::string s) { /*...*/ }

что делать с рекурсией интересно

с прямой рекурсией - return same_fun(/*...*/); видимо ничего сделать нельзя

с прямой рекурсией - return same_fun(/*...*/); видимо ничего сделать нельзя

там сейчас работает потому что первый return гарантирует результат

там сейчас работает потому что первый return гарантирует результат

с чистым auto да, а тут у нас уже std::variant<auto>

с чистым auto да, а тут у нас уже std::variant<auto>

в общем кажется, что user_defined_auto_deduction мы не решим

хотя очень хочется иметь ветки nullopt

а вот typedef throws(checked_exceptions) some_type мы наверное решим

в синтаксисе саттера причем, считаем что throws(true) это throws (true -> any_type)

в общем кажется, что user_defined_auto_deduction мы не решим

придумай пример с рекурсией, пожалуйста, мне ничего адекватного в голову не лезет, хотя уже начинаю понимать в чём проблема

auto fib(int x) { if (x <= 1) return 1; return fib(x - 1) + fib(x - 2); }

текущие правила говорят ОК, потому что return 1 дает int и int+int это int

с этим понятно, но хочется пример под std::variant<auto> или какой-нибудь common_type_t<auto>

ну там рекурсия это непонятный тип, он же self dependent

хотя с common_type можно тот же фибоначчи переделать

будет парадокс

common_type_t<auto> не будет работать, да

он должен получить unspecified_auto в качестве аргумента

std::common_type_t<auto> fib(int x) { if (x <= 0) return int{1}; if (x == 1) return long{1}; return fib(x - 1) + fib(x - 2); }

сложновато придумать какую-то эвристику когда это должно работать, а когда должно выдавать ошибку, чтобы не уходить в бесконечную рекурсию

Вопрос: int * p = new int[0]; UB или нет ?

По факту наблюдаю что оно аллоцирует один байт

Это стандартно, или implementation-specific?

Если стандартно, то зачем. Не лучше ли вернуть nullptr ?

Вопрос: int * p = new int[0]; UB или нет ?

> The effect of dereferencing a pointer returned as a request for zero size is undefined.

https://stackoverflow.com/questions/1087042/c-new-int0-will-it-allocate-memory

Ты на CppCon сидишь?

Да

Крутооо ??

можно уже облизываться?

По факту наблюдаю что оно аллоцирует один байт

а что будет если несколько раз выделить? какие адреса будут?

а что будет если несколько раз выделить? какие адреса будут?

Там выше есть ссылка на stackoverflow

Там выше есть ссылка на stackoverflow

это понятно, но интересует конкретное поведение

это понятно, но интересует конкретное поведение

Выделяет каждый раз новый байт

будут ли одинаковые адреса например

Под linux адреса разные

т.е. зарезервированного адреса под нулевые аллокации у него нет

пример кода сфоткаешь?)

более того, если перегрузить operator new, то он просит именно байт. Так что возможно по другому сделать нельзя

пример кода сфоткаешь?)

А что фоткать, код лежит

пример кода сфоткаешь?)

Не было нормальных примеров на слайдах

А что фоткать, код лежит

под скомбинированный пропозал?

или там не про скомбинированный пропозал?

А просто с примерами модулей лучше просто играться

https://gcc.gnu.org/svn/gcc/branches/c++-modules/

или там не про скомбинированный пропозал?

Про три пропозала

Про три пропозала

скомбиненный в них участвует?

или он ещё не готов?

или он ещё не готов?

Скомбиненый смержили, сам пропозал готов