Интересно, а какие-нибудь требования к к алгоритму вывода auto стандартом предусмотрены? Или компилируемость любой функции, возвращающей auto, зависит от версии компилятора?
Нормальное поведение. Нельзя определить тип из пустого листа инициализации. Я хотела другое, когда тип можно вывести, но компилятор не может, например из-за ограничения самого механизма вывода.
Хорошо, спрошу так. Для вывода типа выражения имеется достаточно информации. Всегда компилятор может вывести тип, или механизм вывода имеет ограничения? Например плохо работает вывод параметров шаблона класса для очень сложных классов с переменным числом аргументов в шаблоне.
Компилятор всегда способен вывести тип. Иначе это баг. Выведение типа это не новомодная фишка придуманная в угоду смузихипстерам. Это логичное расширение возможностей, предоставляемых компилятором. Все необходимое для вывода типа в компиляторе было уже давным давно, нужно было лишь оформить это в самом языке.
Вывод типов на 100% не работает ни в одном из популярных языков, включая Haskell - тупая машина не может заменить человека. Увы, специально не записывал такие случаи)
А у вас CTAD только недавно появился, да? Я поковырял только что,
std::vector v{1,2}; можно только с c++17 делать, до него нужно руками писать std::vector<int>.
Правильно, статический язык не вывести типы не может. Правда таких языков почти нет, а всё остальное - бездарная скриптуха с фейковым выводом. От того такие вопросы и появляются.
А у вас CTAD только недавно появился, да? Я поковырял только что, std::vector v{1,2}; можно только с c++17 делать, до него нужно руками писать std::vector.
Зачем ты закукарекал о C++17? Одно никак не связано с другим.
так не получится:
Ты обгадился со всем остальным и решил ретранслировать методичку? Не сработает. В говнорасте там нет никакого вывода типов. Тебя обманули.
А непопулярный Nemerle ЕМНИП итеративно решал неполную систему уравнений.
Ну это для функциональщины считай норма алгоритм Хиндли — Милнера тоже приводится к системе уравнений.
В том же расте вообще пролог встроили чтобы разрешать свойства трайтов https://rust-lang.github.io/chalk/book/
Скажи это какому-нибудь GHC и хаскелю, там тупняк компилятора обычное дело, когда он не справляется с дюжей полиморфностью вида a -> a -> a
Ну тут как бы подразумевался с++ во-первых, во-вторых как не крути это все равно баг компилятора, так как он должен справляться даже с дюжей полиморфностью.
Нет, это не баг. В скриптухе нету типов и какой-либо вывод это прикрученный сбоку костыль, который не призван и не может что-то выводить.
К тому же полиморфизма в бездарной скриптухе типа хаскеля не существует в принципе. Весь код там реально мономорфный, типизированный подтипом. А какие-то потуги получить иногда чего-то большего в каких-то редких случаях - это не вывод типов.
Поэтому в скриптухе это не является багой. Это является базовым её свойством. Ситуация примерно так же, что с каким-нибудь пистоном в какой-нибудь ideшке. Типизации нет, но какие-то потуги что-то получить предприняты. И в каком-то случае это работает, но во всех и даже большинстве случаев это работать не будет.
Потому что пистон и любая другая скриптуха - никак на типизацию не полагается. Это не статический язык.
не выводит, хотя контекстной информации достаточно.
Ну как по мне это как раз ограничение реализации, вызванное нежеланием усложнять реализацию компилятора. Так-то ведь вся информация у компилятора есть.
Перефразирую свое утверждение - теоретически компилятор всегда способен вывести тип, на практике же есть различные ограничения, например в виде той же сложности реализации.
Ну как по мне это как раз ограничение реализации, вызванное нежеланием усложнять реализацию компилятора. Так-то ведь вся информация у компилятора есть.
Зачем ты повторяешь херню написанную идиотами? Никакой «нужной информации» в контексте не существует. Обезьяна просто тупая. Там может быть хоть vector хоть vector.
на практике же есть различные ограничения, например в виде той же сложности реализации.
Никаких ограничений. Здесь вывод типов попросту невозможен, потому что код истинно полиморфен.
Обезьяна просто тупая и «думает»(хотя думать это слишком сильно для неё), что vector в С++ это какое-то интерфейс из какой-то говноскриптухи. Но это не интерфейс. Это полностью полиморфный тип.
Поэтому vec может быть преобразован в vec без каких-либо проблем.
компилятор сам выводит тип функции. Думаю, говорить, что это очень удобно, особенно в метапрограммировании, не нужно?
При чем выводит также если есть несколько точек выхода из функции
auto square(long num) {
if (num < 0)
return num * num; // здесь возвращаем long
return 0.0; // здесь возвращаем double
}
// Проверяем что типом результата функции является double
static assert(is(typeof(square(0L)) == double));
Компилятор D прекрасно понимает, что если из функции может вернуться и значение типа long и значение типа double, то типом результата должен быть именно double. Если же типы не могут быть неявно сконвертированы в общий тип (типа int и string), тогда возникает ошибка компиляции конечно.
Ну тут как бы с точки зрения компилятора ему суют incomplete type. С точки зрения кодера ему хочется чтобы компилятор механически дополнил этот самый incomplete type. Отбросим ленивых кодеров в сторону и признаем, что такая фича компилятора полезна в метапрограммировании, поскольку упрощает код и повышает его читабельность, но сложность реализации компилятора возрастает.
Поэтому тут и он прав, и ты. Тут кто с какой точки зрения смотрит.
С точки зрения кодера ему хочется чтобы компилятор механически дополнил этот самый incomplete type.
Нет, ещё раз повторю - это так не работает. Вывести здесь тип невозможно, потому как запить с ТЗ системы типов неоднозначна.
что такая фича компилятора полезна в метапрограммировании,
Абсолютно бесполезна. При наличие подобной херни система типов в недоязычке будет настолько примитивной, что никакого метапрограммирования у тебя в принципе не будет.
К тому же в данном случае однозначная запись return {}; - работает. И никакой vector{} там не нужен.
Поэтому тут и он прав, и ты. Тут кто с какой точки зрения смотрит.
Нет, здесь сектант просто нажрался пропаганды и перепутал скриптуху с реальностью.
В связи с тем, что vec не полиморфен. Эта запись, которая vec{} - означает vec<any>{}. Тип T вообще ни на что не влияет. И vec может быть преобразован к чему угодно.
Очевидно про какой-либо полиморфизм в рамках подобной скриптухе ты можешь забыть. И эта обезьяна просто настолько тупая, что не может осознать ничего сложнее примитивности его бездарной скриптухи.
Тут банальный value initialization для пустого init list
Нет. Для инициализации необходимо знать тип инициализируемого. Просто так инициализировать непонятно что нельзя. Какой именно там вид инициализатора - ничего не значит.
Тут проблема такая, что ООП-языки почти все поголовно вводят перегрузку функций (в Аде вообще до предела довели эту идею). А с перегрузкой такая история, что она сильно мешает выводу типов. Вот, и хотели как лучше, а получилось как всегда.
А перегрузка типов существует даже в хаскеле. Там иногда без аннотаций тоже не обойтись.