Эволюция Kotlin

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

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

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

• Оставаться в постоянной связи с пользователями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 (kotlin-stdlib) для стабильных платформ в соответствии с изложенными выше принципами. Изменения в контрактах для ее API проходят те же процедуры, что и изменения в самом языке.

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

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

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

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