Про вывод типов компилятором

Если у тебя ошибка компиляции, то не может, иначе может

Ну вот тебе пример: https://gcc.godbolt.org/z/Ev3Wq3

Вот без рекурсии: https://gcc.godbolt.org/z/8Yacbo

Интересно, а какие-нибудь требования к к алгоритму вывода auto стандартом предусмотрены? Или компилируемость любой функции, возвращающей auto, зависит от версии компилятора?

9.2.8.5 Placeholder type specifiers тут: https://isocpp.org/files/papers/N4860.pdf

Нормальное поведение. Нельзя определить тип из пустого листа инициализации. Я хотела другое, когда тип можно вывести, но компилятор не может, например из-за ограничения самого механизма вывода.

Вот пример из стандарта: https://gcc.godbolt.org/z/85YM49

Хорошо, спрошу так. Для вывода типа выражения имеется достаточно информации. Всегда компилятор может вывести тип, или механизм вывода имеет ограничения? Например плохо работает вывод параметров шаблона класса для очень сложных классов с переменным числом аргументов в шаблоне.

Всегда, насколько знаю. decltype(auto) точный тип, auto - тип на который сделали decay(отбрасывает &, &&, const, volatile)

Вот можешь ещё тут посмотреть, тут проще читать чем стандарт: https://en.cppreference.com/w/cpp/language/auto

decltype(auto) точный тип

Щито??? Ты вообще читал, как из типа выражения expr определяется тип, который будет представлять decltype(expr)?

Читал, и что не так? Полные правила написаны как в стандарте, так и в cppreference.

Я написал в двух словах характеристики, которых достаточно для многих случаев:

decltype(auto) сохраняет модификаторы

auto нет:

https://gcc.godbolt.org/z/776vfK

Читал, и что не так?

Ок, точный тип чего даёт decltype(auto)?

Компилятор всегда способен вывести тип. Иначе это баг. Выведение типа это не новомодная фишка придуманная в угоду смузихипстерам. Это логичное расширение возможностей, предоставляемых компилятором. Все необходимое для вывода типа в компиляторе было уже давным давно, нужно было лишь оформить это в самом языке.

Скажи это какому-нибудь GHC и хаскелю, там тупняк компилятора обычное дело, когда он не справляется с дюжей полиморфностью вида a -> a -> a

Вывод типов на 100% не работает ни в одном из популярных языков, включая Haskell - тупая машина не может заменить человека. Увы, специально не записывал такие случаи)

ни в одном из популярных языков

…А непопулярный Nemerle ЕМНИП итеративно решал неполную систему уравнений. Выводя даже типы параметров по использованию (только это уже дичь ИМХО).

std::vector<int> foo() {
  return std::vector<int>{};
}

выводит

std::vector<int> foo() {
  return std::vector{};
}

не выводит, хотя контекстной информации достаточно.

return {};

же

А у вас CTAD только недавно появился, да? Я поковырял только что, std::vector v{1,2}; можно только с c++17 делать, до него нужно руками писать std::vector<int>.

Ну, в принципе, я хотел сказать, что иногда вывод типа возможен только по call-site (типа как здесь https://doc.rust-lang.org/stable/rust-by-example/types/inference.html), и если бы я захотел так сделать в c++, то (пока?) так не получится:

std::vector v{}; // nope
v.push_back(2);

А Rust недавно появился да? Там ещё не придумали что можно выводить тип возвращаемого значения у функций?

Я тут поковырял rust nightly, и пока возвращаемое значение у функции нужно писать руками :(

pub fn square(num: i32) /*-> i32*/ { // nope
    num * num
}

Дарю идею.

Ну… это их решение, все нормально. Что сказать-то хотел?

Надеюсь и не запилят этот ужас. А для бытовых задач есть -> impl T.

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

А у вас CTAD только недавно появился, да? Я поковырял только что, std::vector v{1,2}; можно только с c++17 делать, до него нужно руками писать std::vector.

Зачем ты закукарекал о C++17? Одно никак не связано с другим.

так не получится:

Ты обгадился со всем остальным и решил ретранслировать методичку? Не сработает. В говнорасте там нет никакого вывода типов. Тебя обманули.

А чего ты так быстро слился? Ой, оказалось, что вывода типов в недоязычке нет? Как же так? Они не обгадились - это их решение. Сильно.

А Rust недавно появился да? Там ещё не придумали что можно выводить тип возвращаемого значения у функций?

Там просто принципиально отказались от этого. В OCaml откуда и содран вывод типов раста возвращаемое значение без проблем выводится.

А непопулярный Nemerle ЕМНИП итеративно решал неполную систему уравнений.

Ну это для функциональщины считай норма алгоритм Хиндли — Милнера тоже приводится к системе уравнений.
В том же расте вообще пролог встроили чтобы разрешать свойства трайтов https://rust-lang.github.io/chalk/book/

Там просто принципиально отказались от этого. В OCaml откуда и содран вывод типов раста возвращаемое значение без проблем выводится.

Да. Поэтому приводить раст как язык с хорошим выводом типов, как минимум странно.

let square x = x * x

Да. Поэтому приводить раст как язык с хорошим выводом типов, как минимум странно.

Ну вывод вполне хороший на уровне того же OCaml, но сильно ограниченный, только внутри функций. В том же немерле вроде такое же ограничение было.

да сколько угодно

auto dfs(const std::vector<std::vector<int>>& graph, int v, int p) {
  for (auto to: graph[v]) 
    if (to != p) 
      dfs(graph, to, v);
}

либо заменить auto на void, либо дописать -> void после сигнатуры

И что же ты высрал? И к чему?

релевантный пример кода для топикстартера. А если тебе, дурачок, тут что-то не понятно - иди читай книжки по C++

Скажи это какому-нибудь GHC и хаскелю, там тупняк компилятора обычное дело, когда он не справляется с дюжей полиморфностью вида a -> a -> a

Ну тут как бы подразумевался с++ во-первых, во-вторых как не крути это все равно баг компилятора, так как он должен справляться даже с дюжей полиморфностью.

Вычисление типа на Тьюринг-полной машине обломается на проблеме останова.

Нет, это не баг. В скриптухе нету типов и какой-либо вывод это прикрученный сбоку костыль, который не призван и не может что-то выводить.

К тому же полиморфизма в бездарной скриптухе типа хаскеля не существует в принципе. Весь код там реально мономорфный, типизированный подтипом. А какие-то потуги получить иногда чего-то большего в каких-то редких случаях - это не вывод типов.

Поэтому в скриптухе это не является багой. Это является базовым её свойством. Ситуация примерно так же, что с каким-нибудь пистоном в какой-нибудь ideшке. Типизации нет, но какие-то потуги что-то получить предприняты. И в каком-то случае это работает, но во всех и даже большинстве случаев это работать не будет.

Потому что пистон и любая другая скриптуха - никак на типизацию не полагается. Это не статический язык.

не выводит, хотя контекстной информации достаточно.

Ну как по мне это как раз ограничение реализации, вызванное нежеланием усложнять реализацию компилятора. Так-то ведь вся информация у компилятора есть.

Перефразирую свое утверждение - теоретически компилятор всегда способен вывести тип, на практике же есть различные ограничения, например в виде той же сложности реализации.

Ну как по мне это как раз ограничение реализации, вызванное нежеланием усложнять реализацию компилятора. Так-то ведь вся информация у компилятора есть.

Зачем ты повторяешь херню написанную идиотами? Никакой «нужной информации» в контексте не существует. Обезьяна просто тупая. Там может быть хоть vector хоть vector.

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

Никаких ограничений. Здесь вывод типов попросту невозможен, потому что код истинно полиморфен.

Обезьяна просто тупая и «думает»(хотя думать это слишком сильно для неё), что vector в С++ это какое-то интерфейс из какой-то говноскриптухи. Но это не интерфейс. Это полностью полиморфный тип.

Поэтому vec может быть преобразован в vec без каких-либо проблем.

В D так можно уже давным давно можно делать:

auto square(uint num) {
    return num * num;
}

компилятор сам выводит тип функции. Думаю, говорить, что это очень удобно, особенно в метапрограммировании, не нужно?

При чем выводит также если есть несколько точек выхода из функции

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{} там не нужен.

Поэтому тут и он прав, и ты. Тут кто с какой точки зрения смотрит.

Нет, здесь сектант просто нажрался пропаганды и перепутал скриптуху с реальностью.

В его скриптухе это выглядит так:

interface vec<T> {
  ...
}

vec<int> () { return vec{}; }

В связи с тем, что vec не полиморфен. Эта запись, которая vec{} - означает vec<any>{}. Тип T вообще ни на что не влияет. И vec может быть преобразован к чему угодно.

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

однозначная запись return {}; - работает

Причем тут вывод типов? Тут банальный value initialization для пустого init list

Причем тут вывод типов?

Притом.

Тут банальный value initialization для пустого init list

Нет. Для инициализации необходимо знать тип инициализируемого. Просто так инициализировать непонятно что нельзя. Какой именно там вид инициализатора - ничего не значит.

То, что в контексте return доступен результирующий тип - доказывается очень просто: https://godbolt.org/z/s6jYv5

Я имел дело с Nemerle. Те же грабли.

Тут проблема такая, что ООП-языки почти все поголовно вводят перегрузку функций (в Аде вообще до предела довели эту идею). А с перегрузкой такая история, что она сильно мешает выводу типов. Вот, и хотели как лучше, а получилось как всегда.

А перегрузка типов существует даже в хаскеле. Там иногда без аннотаций тоже не обойтись.

Для инициализации необходимо знать тип инициализируемого

Который заранее известен по декларации самой функции - полный тип возвращаемого типа указан - него выводить.

auto f(auto x) {
  return x;
}

auto x = f(x);

в общем случае компилятор не может вывести тип по выражению слева от =.

более простой вариант:

auto f();

int x = f();

ты запутал компилятор

return {}

ты наверное путаешь ctad с deduction guides. ctad - это std::tuple t(2, 3.5, "abc"s). советую почитать что-нибудь про с++.

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

А почему такой язык как например lisp всегда выводит типы без ошибок?

auto f(auto x)

Так нельзя. Правильно так

template <class T>
auto f(T x) {
  return x;
}

auto b = f(true);
auto i = f(10);

С С++20 можно просто auto

Всё там норм.

Вот пруф: https://en.cppreference.com/w/cpp/language/function_template#Abbreviated_function_template

Так нельзя

да? а мне множно.

template <class T>
auto f(T x) {
  return x;
}

эквивалентно

auto f(auto x) {
  return x;
}

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

https://godbolt.org/z/n5xbha