Comments 5
Скажите, а ваш вариант null-safety от того же Kotlin отличается? Просто я слышал что есть какое-то sound null safety. Не знаю что это такое. Надеюсь правильно запомнил название
Как там объяснил Filip Hracek:
Когда Dart определяет, что переменная non-nullable, то эта переменная считается всегда non-nullable. В случае non-sound null safety это не так и надо делать дополнительные проверки во время выполнения кода. Поэтому в варианте sound null safety код выполняется быстрее.
Но, если вы не покидаете экосистему Котлин, то никаких танцев с бубном не будет.
В Котлин null это часть языка которая помогает, а не мешает.
elizarov.medium.com/null-is-your-friend-not-a-mistake-b63ff1751dd5
Как раз закончил писать небольшой телеграмм-бот с использованием null-safety, чувства остались смешанные. С одной стороны, я рад, что система подсвечивает мне случаи, которые я, скорее всего, пропустил бы. С другой, такого количества ручных проверок на null в моём коде не было никогда, и это раздражает)) хотя не исключаю, что я как-то не так в целом всё спроектировал…
Наличие большого количества пакетов, не поддерживающих null-safety, также на данном этапе усложняет жизнь. То анализатор заставляет делать проверки там, где они ну точно не нужны, а то предлагает отказаться от "лишней" проверки там, где ну точно может выскочить null. Со временем это, конечно, пройдет, но на данный момент…
А ещё Android Studio пока не умеет запускать тесты в null-safety проектах, приходится вручную через консоль. Ну, мелочь, в целом.
Мне кажется, на данный момент в проектах, не являющихся библиотеками, лучше не использовать null-safety, пока на неё не мигрирует большинство зависимостей. Но я в языке новичок, могу ошибаться, конечно)) А в пет-проектах любые эксперименты хороши.
В целом изменение позитивное, чем больше ошибок обнаружится до запуска, тем лучше!
Объявление о бета-тестировании null-safety Dart. Начало процесса миграции пакетов в надежное и безопасное состояние