Вывод локального типа против экземпляра

Причина запрета вывода типов для полей и возвращаемых методов заключается в том, что API должны быть стабильными; доступ к полю и вызов метода связаны дескриптором во время выполнения, поэтому вещи, которые вызывают тонкие изменения в выводимых типах, могут привести к ужасным поломкам существующих скомпилированных клиентов, если изменение реализации приведет к изменению выведенного типа (стирание по модулю). Таким образом, использование это для реализации, но не для API, является разумным руководящим принципом.

Резонно спросить: «А как насчет приватных полей и методов?» И действительно, мы вполне могли бы сделать это. Как и все дизайнерские решения, это компромисс; это позволило бы использовать вывод в большем количестве мест в обмен на большую сложность пользовательской модели. (Меня не волнует сложность спецификации или компилятора; это наша проблема.) Легче рассуждать о «выводе для локальных переменных — да, полях и методах — нет», чем добавлять различные эпициклические рассуждения вроде «но поля и методы в порядке, если они закрыты». Проведение линии там, где мы это сделали, также означает, что последствия для совместимости изменения поля или метода с частного на нечастный не имеют случайных взаимодействий с логическим выводом.

Таким образом, если сделать это таким образом, то язык станет проще, но функция не станет менее полезной.

Различные причины:

1. Видимость и тип ортогональны — одно не должно влиять на другое. Если бы частные переменные можно было инициализировать с помощью var, вам пришлось бы изменить это, делая их защищенными или общедоступными.

2. Поскольку var использует правую часть для определения типа, такие закрытые поля всегда необходимо сразу инициализировать. Если вы перемещаете инициализацию в конструктор, вам нужно сделать тип явным.

3. С помощью var компилятор может вывести типы, которые вы в настоящее время не можете выразить в Java (например, типы пересечения, такие как Comparable & Serializable). Конечно, вы можете в конечном итоге полагаться на эти конкретные типы, и когда вам в какой-то момент по какой-либо причине придется прекратить использование var, вам может потребоваться довольно много рефакторинга, чтобы ваш код работал.

Не то чтобы было совершенно невозможно превратить эти переменные в поля, которые можно проверить с помощью Reflection. Например, вы можете сделать

var l = new ArrayList<String>();
l.add("text");
System.out.println(l);
System.out.println(
  new Object(){ { var x = l; } }.getClass().getDeclaredFields()[0].getGenericType()
);

В текущей версии он просто печатает ArrayList, поэтому фактический универсальный тип не был сохранен в файле класса анонимного внутреннего класса, и маловероятно, что это изменится, поскольку поддержка этого самоанализа не является фактической целью. Это также особый случай, когда тип обозначается как ArrayList<String>. Чтобы проиллюстрировать другой случай:

var acs = true? new StringBuilder(): CharBuffer.allocate(10);
acs.append("text");
acs.subSequence(1, 2);
System.out.println(
  new Object(){ { var x = acs; } }.getClass().getDeclaredFields()[0].getGenericType()
);

Тип acs является типом пересечения Appendable и CharSequence, что демонстрируется вызовом метода любого интерфейса для него, но поскольку не указано, выводит ли компилятор #1 extends Appendable&CharSequence или #1 extends CharSequence&Appendable, не указано, будет ли код печатать java.lang.Appendable или java.lang.CharSequence .

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

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

Развивая ответ Николая (в частности, его причину № 2), в предлагаемом проекте JLS 10 говорится, что и var e;, и var g = null; являются незаконными. для локальных переменных и не зря; неясно из правой части (или ее отсутствия), какой тип вывести для var.

В настоящее время неконечные переменные экземпляра автоматически инициализируются в зависимости от их типа (примитивы к 0 и false и ссылки к null, как я уверен, вы уже знаете). Выведенный тип переменной экземпляра останется неясным, если только он не будет инициализирован при объявлении или в конструкторе(ах) соответствующего класса.

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

Было бы разумным решением разрешить var для закрытых полей (IMO). Но его отсутствие делает функцию проще.

Кроме того, его можно будет добавить в каком-нибудь будущем выпуске, когда будет больше опыта с выводом только локального типа, а удалить функцию будет намного сложнее.