Эволюция Kotlin

Принципы прагматической эволюции

Kotlin разработан как прагматичный инструмент для программистов. В отношении эволюции языка его прагматизм воплощён в следующих принципах:

• Сохранять актуальность языка с течением времени.

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

• Обеспечить удобство обновления до новых версий.

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

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

Удобные обновления. Несовместимые изменения, такие как удаление элементов из языка, могут привести к болезненной миграции с одной версии на другую, если не будут выполнены надлежащие меры предосторожности. Мы всегда будем объявлять о таких изменениях заранее, помечать элементы как устаревшие и предоставлять автоматизированные инструменты миграции до того, как произойдёт изменение. К моменту внесения изменений в язык мы хотим, чтобы большая часть кода в мире уже была обновлена, и таким образом не возникло проблем с миграцией на новую версию.

Цикл обратной связи. Процесс устаревания функций требует значительных усилий, поэтому мы стремимся минимизировать количество несовместимых изменений в будущем. Помимо использования нашего опыта, мы считаем, что лучший способ подтверждения дизайна — это его тестирование в реальных условиях. Прежде чем закрепить что-либо окончательно, мы хотим, чтобы оно было проверенным в работе. Вот почему мы используем любую возможность предоставлять ранние версии наших разработок в производственных версиях языка, но в одном из предварительно стабильных состояний: Экспериментальный, альфа или бета. Такие функции не стабильны, они могут быть изменены в любое время, и пользователи, которые выбирают их для использования, делают это сознательно, понимая, что им придётся столкнуться с возможными проблемами миграции в будущем. Эти пользователи предоставляют неоценимую обратную связь, которую мы собираем, чтобы совершенствовать дизайн и сделать его надёжным.

Несовместимые изменения

Если при обновлении с одной версии на другую какой-то код, который раньше работал, больше не работает, это несовместимое изменение в языке (иногда называемое «разрушающим изменением»). В некоторых случаях могут возникнуть споры о том, что именно подразумевается под «больше не работает», но это, безусловно, включает следующее:

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

• Код, который выполнялся нормально, теперь генерирует исключение.

Менее очевидные случаи, относящиеся к «серой области», включают различное обращение с краевыми случаями, генерирование исключения другого типа, чем раньше, изменение поведения, наблюдаемого только через рефлексию, изменения недокументированного/неопределённого поведения, переименование бинарных артефактов и т. д. Иногда такие изменения очень важны и значительно влияют на процесс миграции, иногда они незначительны.

Вот некоторые примеры того, что определённо не является несовместимым изменением:

• Добавление новых предупреждений.

• Включение новых конструкций языка или ослабление ограничений для существующих.

• Изменение частных/внутренних API и других деталей реализации.

Принципы «Сохранение актуальности языка» и «Удобные обновления» предполагают, что несовместимые изменения иногда необходимы, но их следует вводить с осторожностью. Наша цель — своевременно информировать пользователей о предстоящих изменениях, чтобы они могли комфортно мигрировать свой код.

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

• Обновление до версии A (где объявляется изменение)

  • Просмотр предупреждений о предстоящем изменении

  • Миграция кода с помощью средств

• Обновление до версии B (где происходит изменение)

  • Отсутствие проблем

На практике некоторые изменения нельзя точно обнаружить во время компиляции, поэтому предупреждения не могут быть отображены, но пользователи будут проинформированы об этом в примечаниях к выпуску версии A, что изменение произойдёт в версии B.

Процесс принятия решений

JetBrains, первоначальный разработчик Kotlin, управляет его развитием с помощью сообщества и в соответствии с Kotlin Foundation.

Все изменения языка программирования Kotlin контролируются Главным разработчиком языка (в настоящее время Роман Елизаров). Главный разработчик имеет окончательное слово во всех вопросах, связанных с эволюцией языка. Кроме того, несовместимые изменения для полностью стабильных компонентов должны быть одобрены Комитетом по языку, назначенным Kotlin Foundation (в настоящее время в состав входят Джеффри ван Гох, Уильям Р. Кук и Роман Елизаров).

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

Релизы функций и инкрементные релизы

Стабильные релизы с версиями 1.2, 1.3 и т. д. обычно считаются релизами функций, вносящими существенные изменения в язык. Обычно мы публикуем инкрементные релизы, пронумерованные 1.2.20, 1.2.30 и т. д., между релизами функций.

Инкрементные релизы включают обновления инструментов (зачастую с добавлением функций), улучшения производительности и исправления ошибок. Мы стараемся поддерживать совместимость таких версий друг с другом, поэтому изменения в компиляторе в основном представляют собой оптимизации и добавление/удаление предупреждений. Предварительные стабильные функции, конечно, могут быть добавлены, удалены или изменены в любое время.

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

Библиотеки

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

В идеале новая версия библиотеки может использоваться как «прямая замена» более старой версии. Это означает, что обновление двоичной зависимости не должно вызывать ошибок, даже если приложение не перекомпилируется (это возможно при динамической линковке).

С одной стороны, для достижения этого компилятор должен гарантировать определенную стабильность ABI в рамках ограничений отдельной компиляции. Именно поэтому каждое изменение в языке рассматривается с точки зрения бинарной совместимости.

С другой стороны, многое зависит от того, насколько осторожны авторы библиотек в отношении изменений, которые безопасно вносить. Поэтому очень важно, чтобы авторы библиотек понимали, как изменения в исходном коде влияют на совместимость, и следовали определенным рекомендациям, чтобы поддерживать стабильность как API, так и ABI своих библиотек. Вот некоторые предположения, которые мы делаем при рассмотрении изменений языка с точки зрения развития библиотек:

• Код библиотеки всегда должен явно указывать типы возвращаемых значений общедоступных/защищенных функций и свойств, никогда не полагаясь на вывод типов для общедоступного API. Незначительные изменения в выводе типов могут привести к непреднамеренному изменению типов возвращаемых значений, что приведет к проблемам бинарной совместимости.

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

Авторы библиотек могут использовать аннотации @Deprecated и @RequiresOptIn для управления развитием их API-интерфейса. Обратите внимание, что @Deprecated(level=HIDDEN) можно использовать для сохранения бинарной совместимости даже для объявлений, удаленных из API.

Также, по соглашению, пакеты с именем «internal» не считаются общедоступным API. Весь API, находящийся в пакетах с именем «experimental», считается предварительно стабильным и может измениться в любой момент.

Мы развиваем Kotlin Standard Library (kotlin-stdlib) для стабильных платформ в соответствии с вышеизложенными принципами. Изменения в контрактах для его API проходят те же процедуры, что и изменения в языке.

Ключи компилятора

Ключи командной строки, принимаемые компилятором, также являются своего рода общедоступным API, и они подчиняются тем же соображениям. Поддерживаемые флаги (те, у которых нет префикса «-X» или «-XX») могут быть добавлены только в релизах функций и должны быть надлежащим образом объявлены устаревшими перед их удалением. Флаги «-X» и «-XX» являются экспериментальными и могут быть добавлены и удалены в любое время.

Инструменты совместимости

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