Почему в жабе нет локального вывода типов?

подожди еще 20 лет, жаба для этого слишком молода.

ps. там для тернарки компилятор не может адекватно вывести тип, а ты auto

потому что тогда это будут кресты?

Потому что дизайнеры языка считают это ненужным.

ps. там для тернарки компилятор не может адекватно вывести тип

Это как?

емнип не скомпилируется:

List<Integer> first = null;
List<Integer> list = first == null? Collections.emptyList() : first;

и там еще много приятных случаев (напр. http://stackoverflow.com/questions/12108998/wrong-return-type-when-using-if-v... )

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

Не добавили

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

Это как бы не особо в тему вопроса. Тип выражения справа от знака равно вычисляется без типа в объявлении. Т.е. будет там auto или что-то другое абсолютно ни на что не влияет. auto просто забирает тип rhs в lhs.

Так, например, ошибки будут в обеих строках на C++:

true ? "literal" : 1;
auto trash = true ? "literal" : 1;

Потому что так (не) захотели авторы языка.

Ну, по типу auto в крестах.

Блджад, ну не удобно же эти ваши ауто читать. Какой укуренный чудак его придумал?

Это карма.

Автолюбитель какой-то.

Нужно же было как-то избавляться от my_lovely_namespace::class_of_shit<another_damn_class>::iterator

Блджад, ну не удобно же эти ваши ауто читать

оно удобно при инициализации простым выражением (литерал, или переменная, например). иногда вызовом функции

Потому что auto или var это зло, и им не место в строго типизированном Объектно-Ориениированном языке.

Для этого typedef вообще-то придумали.

Ну так это, «программисты» на JavaScript и PHP дорвались до плюсов, и притащили с собой свое говно.

Нужно же было как-то избавляться от my_lovely_namespace::class_of_shit<another_damn_class>::iterator

Не нужно. Читаешь код и них** не понятно, «кто на ком стоял». Вызывается какая-то функция, ее результат суется в auto. Потом по этому auto пускается цикл, к лучшему значению прибавляется 42 и возвращается из метода. Ах да, метод возвращает auto. Красота, чо.

Когда пишутся такие простыни, тоже иногда не очень удобно читать. Анон выше прав, в таком случае typedef, например, отлично подойдёт.

А Collections<Integer>.emptyList() не поможет в данном случае?

ы! пхп-кодер :)

Потому что жабу не разрабатывали и не предназначали для compile-time обобщенного программирования, а без этого auto особо и не нужен.

поможет, но какбы по сигнатуре параметр типа у emptyList должен вычисляться, но в таких (и куче других случаев) оно этого не умеет

Скорее программисты на всяких Haskell и пр. функциональных языках. Оттуда новые фичи плюсов(с поправкой на императивность и «низкоуровневость»).

Раньше джависты так и о лямбдах говорили. Ничего, добавили. Добавят и вывод типов когда-нибудь.

Ну вот, например, такая ситуация. С седьмой джавы можно писать как-то так.

List<Yoba> yoby = new ArrayList<>();

auto yoby = new ArrayList<>();

Что мешает запретить бриллиантовый оператор при выводе типа?

Ничто, конечно, но как-то это непоследовательно.

Потому, что Eclipse с IDEA самоубивались.
При тестировании auto жаба раздувалась, впадала в кому и сжигала ядра.

И получится (Array?)List<Object>

И в чем проблема?

В отстутствии локальной проверки типов. Такой код не взлетит:

List<Yoba> yoby = new ArrayList<>();
yoby.add(new Dildo());

В отстутствии локальной проверки типов.

В каком месте она отсутствует?

А если yoby будет List<Object> то вполне.

И в чем проблема?

Проблема в использовании auto с diamond types.

Проблема в использовании auto с diamond types.

Конкретнее можно? Вроде все вполне хорошо выводится.