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

Но для большинства пакетов, которые переведены на нулевую безопасность, все библиотеки будут перенесены в нулевую безопасность.

Изменить: я не совсем уверен, что мы должны здесь делать. Просто добавление "нулевой безопасности" к библиотекам в пакетах, у которых нет language-version> = 2.12.0, вероятно, неправильно.

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

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

@ jcollins-g нужен ли нам когда-нибудь этот тег на уровне участника? В другом месте, например, в pub.dev, мы собираемся рассматривать нулевую безопасность как свойство уровня пакета (либо оно есть у всего пакета, либо его нет).

@ mit-mit В любом случае у меня нет твердого мнения по этому поводу. Можно привести аргумент, что при просмотре корпуса документации API и пересечении границ пакета было бы неплохо узнать, когда вы наткнулись на (или вышли из) нулевой безопасный пакет, и тег-член является одним из способов сделать тот.

Мы могли бы положить его сюда?

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

Часто ли возможно наткнуться на нулевой безопасный пакет на что-то, что не является нулевым безопасным?

На pub.dev анализ в pana классифицирует пакет только как поддерживающий нулевую безопасность , если:

• Языковая версия: >=2.12 ,
• Ни одна из библиотек в пакете не отказывается от нулевой безопасности с использованием _language version marker_ ( // @dart=2.5 ),
• Все зависимости (за исключением dev_dependencies ) в текущем разрешении pub upgrade _supports null-safety_ (в соответствии с этим рекурсивным определением).

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

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

Оказалось, что эту проблему сложно решить из-за https://github.com/dart-lang/sdk/issues/43903, которую, как я понимаю, также сложно решить из-за флага эксперимента и того, как он используется. для не допускающего значения NULL. Эта проблема может «исчезнуть», когда флаг станет дефолтным. Я склонен допускать, чтобы теги были ошибочными в течение короткого периода времени, предполагая, что в ближайшее время этот флаг станет установленным по умолчанию в анализаторе, поскольку работа над этим потребует значительных усилий. Обсудим с командой анализаторов в понедельник, большинство из них сегодня нет.

Плохие новости. Установка флага по умолчанию не решит проблему. Таким образом, нам нужна дополнительная работа, чтобы исправить эту проблему. Хорошей новостью является то, что @scheglov уже проделал тяжелую работу в анализаторе и dartdoc для решения этой проблемы в # 2309, хотя его необходимо обновить и исправить некоторые проблемы совместимости с Windows. Как только эта работа будет завершена, можно будет исправить эту ошибку.

Сейчас работаем, чтобы начать PR на основе № 2309 с исправлениями проблем, с которыми он столкнулся, и разрешением конфликтов слияния.

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

Моя вторая попытка «исправить» это просто переопределила логику чтения pubspec внутри dartdoc. Это было глупо, но сработало бы. @scheglov указал, что это могло быть вызвано тем, что пакеты не были переданы в AnalysisDriver, и действительно, мы не смогли этого сделать.

2411 исправляет проблему, передавая правильную структуру пакета в AnalysisDriver, что приводит к исправлению.

Зарегистрирована ошибка № 2410, связанная с переносом на AnalysisContextCollection, поскольку неспособность устранить эту задолженность, несомненно, приведет к более запутанным проблемам, подобным этой, в будущем.

Зарегистрирована ошибка №2409 для реализации комментария @mit-mit об изменении положения нулевого тега безопасности.

Закроется и перейдет к публикации новой версии после приземления # 2411.