Мы вовсю работаем над Go 1.13, релиз которого, надеюсь, состоится в начале августа этого года. Это первый релиз, который будет включать в себя изменения конкретно в языке (а не просто незначительные правки спецификации) после длительного моратория на любые такие изменения.
Чтобы прийти к этим изменениям в языке, мы начали с нескольких жизнеспособных предложений (proposals), отобранных из гораздо большего списка предложений по Go 2, в соответствии с новым процессом оценки предложений, описанным в посте "Go 2, here we come!". Мы хотели, чтобы первичный отбор предложений нами играл относительно малую роль и, по большей части, не вызывал споров, чтобы с большой вероятностью они бы прошли весь этот процесс. Предложенные изменения должны были быть обратно совместимыми, чтобы сломать как можно меньше, поскольку модули (которые в будущем позволят выбрать версию языка для конкретного модуля) пока еще не являются режимом сборки по умолчанию. Коротко, текущий начальный этап изменений был больше направлен на то, чтобы снова сдвинуться с мертвой точки и получить опыт, а не на решение больших проблем.
Наш изначальный список предложений — Unicode в общем виде в идентификаторах, двоичные целочисленные литералы, разделители для числовых литералов, битовые сдвиги на знаковое целое — был и укорочен, и расширен. Предложение по Unicode в общем виде в идентификаторах не пережило сокращения, поскольку мы не успели вовремя составить дизайн-документ. Предложение по двоичным целочисленным литералам было значительно расширено и привело к всестороннему пересмотру и модернизации синтаксиса числовых литералов Go. Также мы добавили черновой вариант предложения Go 2 по проверке ошибок, который был частично принят.
С учетом этих начальных изменений в Go 1.13, пришло время задуматься о будущем Go 1.14 и определить, что мы хотим изменить далее.
Цели, которые мы ставим перед Go сегодня, такие же, как и в 2007 году: сделать разработку программного обеспечения масштабируемой. Три главных препятствия на пути к улучшению масштабируемости для Go — это отсутствие системы управления пакетами и версиями, поддержки более хорошей системы обработки ошибок, и дженериков.
С улучшением системы модулей Go решается проблема управления пакетами и версиями. Остаются улучшение обработки ошибок и дженерики. Мы работали над обеими проблемами и представили черновики дизайн-документов на прошлогоднем GopherCon в Денвере. С тех пор мы постепенно улучшали их. По обработке ошибок мы опубликовали значительно переработанное и упрощенное предложение (см. ниже). Что касается дженериков, то мы работаем над этим, на эту тему на GopherCon в Сан-Диего в этом году состоится выступление Иэна Лэнса Тейлора "Generics in Go", однако мы пока не дошли до этапа, когда могли бы предоставить конкретное предложение.
Мы также хотим продолжить понемногу улучшать сам язык. Для Go 1.14 мы выбрали следующие предложения:
#32437. Встроенная функция проверки на ошибку — "try" (дизайн-документ).
Это наше предложение по улучшению обработки ошибок. Несмотря на то, что предложенное обратно совместимое расширение языка невелико, мы ожидаем значительного влияния на код обработки ошибок. Это предложение уже вызвало огромное количество комментариев, и за этим не так просто следить. Мы рекомендуем начать с первого комментария для краткого описания, а затем прочитать подробный дизайн-документ. В первом комментарии есть пара ссылок на краткое содержание отзывов. Пожалуйста, следуйте рекомендациям по обратной связи (см. раздел "Следующие шаги") перед ответом.
#6977. Разрешить встраивание перекрывающихся интерфейсов (дизайн-документ).
Это старое обратно совместимое предложение для того, чтобы сделать встраивание (embedding) интерфейсов более толерантным.
#32479. Предупреждать о преобразовании вида string(int) в go vet.
Преобразование вида string(int) давно было добавлено в Go для удобства, однако оно очень путает новичков (string(10) — это "\n", а не "10") и более не оправдано, поскольку сейчас преобразование доступно в пакете unicode/utf8. Поскольку удаление этого преобразования не является обратно-совместимым изменением, мы предлагаем вместо этого выдавать ошибку при выполнении go vet.
#32466. Принять принципы проектирования по криптографии (дизайн-документ).
Это запрос обратной связи по набору принципов проектирования криптографических библиотек, которые мы хотели бы принять. Смотрите также соответствующее предложение по удалению поддержки SSLv3 из crypto/tls.
Мы активно собираем обратную связь по всем этим предложениям. Мы особенно заинтересованы в фактических данных, показывающих, почему предложение может работать плохо на практике, или в проблемных аспектах, которые мы могли упустить при разработке. Убедительные примеры в поддержку предложений также очень полезны. С другой стороны, комментарии, содержащие только личные мнения, менее действенны: мы можем принять их во внимание, но не можем конструктивно работать с ними. Перед ответом, пожалуйста, найдите время, чтобы прочитать подробные дизайн-документы и предыдущие отзывы или их краткое содержание. Ваша тема, возможно, уже была поднята и обсуждена в предыдущих комментариях, особенно в ходе долгих дискуссий.
Если эти предложения не встретят явных проблем, то мы планируем все реализовать в начале цикла разработки Go 1.14 (начало августа 2019 г.), чтобы это уже можно было оценить на практике. В соответствии с процессом оценки предложений, окончательное решение будет принято в конце цикла разработки (начало ноября 2019 г.).
Спасибо за помощь в улучшении языка Go!
Robert Griesemer, для команды Go
Комментариев нет:
Отправить комментарий