Эволюция Kotlin

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

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

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

• Поддерживать постоянную обратную связь с пользователями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Не заметить никаких проблем

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

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

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

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

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

Релизы с новыми функциями и инкрементные релизы

Стабильные релизы с версиями 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» являются экспериментальными и могут быть добавлены и удалены в любое время.

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

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