Какие возможности появились с введением null safety в Dart 2.12?

Слушай, а вот эта ваша null safety в Dart — это вообще, блядь, огонь, ядрёна вошь! Раньше-то как было? Ловишь NullPointerException в рантайме, как дурак, а потом полдня дебажишь, кто тебе null в переменную сунул. А теперь, ёпта, компилятор сам тебя за руку ловит и орёт: "Мужик, ты куда лезешь, там же null может быть, ёб твою мать!".

Вот смотри, как теперь жизнь изменилась:

1. Теперь всё по-честному, не-nullable по умолчанию. Раньше каждая переменная была как хитрая жопа — в любой момент могла оказаться пустой. А теперь если ты написал String, то это строка, а не манда с ушами. Попробуй запихнуть туда null — получишь по шапке сразу, на этапе компиляции.

   String name = 'Flutter'; // Всё чики-пуки
   String name = null; // Компилятор: "Какого хуя? Сам от себя охуел? Я тебе разрешал?"

2. Хочешь по-старому, жить опасно? Пожалуйста, но явно пометь (?). Сказал, что переменная String? — ну окей, значит, можешь быть героем и хранить там null. Но теперь компилятор тебе не даст просто так взять и обратиться к её свойствам. Защита от дурака, блядь.

   String? nickname = null; // Ну ладно, храни свою пустоту.
   print(nickname.length); // А вот тут компьютор тебя останавливает: "Чувак, а если там null? Ты уверен? Доверия ебать ноль".

3. Инструменты для работы с этой nullable-хренью.

   • Безопасный доступ (?.) — типа, "если не null, то сделай, а если null, то да похуй, верни null и иди дальше". Удобно, не надо городить if.

     int? length = nickname?.length; // length либо число, либо тоже null. Чётко.

   • Костыль на случай пиздеца (??) — "если слева хуйня (null), то бери то, что справа". Спасение для дефолтных значений.

     String greeting = 'Hello, ' + (nickname ?? 'Guest'); // Если nickname пустой, гость будет. Красота!

   • Взрывная кнопка (!) — "Я, блядь, на 146% уверен, что тут не null! Если я ошибаюсь — пусть всё ебётся конём!". Рискованно, но иногда надо.

     print(nickname!.length); // Программист клянётся, что nickname не null. Если соврал — runtime исключение, всем пи*дец.

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

   void createUser({required String name, required int age}) { ... }
   // createUser(age: 25); // Ошибка компиляции: "Мужик, а где name? required же, ёбаный насос!"

5. Ленивая инициализация (late) — для умных. Бывает, переменную non-nullable объявить надо сразу, а инициализировать — позже, в конструкторе или в initState. Раньше приходилось пихать туда null и делать вид, что так и надо. Теперь говоришь late — и всё, типа "я ручаюсь, что к моменту использования она будет готова". Обманешь — получишь LateInitializationError и будешь сам виноват.

   class ApiService {
     late final Dio _client; // Не-null, но повиси пока в ожидании.
   
     ApiService(String baseUrl) {
       _client = Dio(BaseOptions(baseUrl: baseUrl)); // А вот теперь инициализирую, всё честно.
     }
   }
   // Если попробовать использовать _client до этой строчки — будет тебе хиросима, сам напросился.

Короче, null safety — это пизда рулю. Сначала, конечно, волнение ебать, привыкать надо, кажется, что везде надо ? ставить. Но потом, когда проект растёт, а ошибок "Cannot read property of null" — ноль ебать, понимаешь, что это гениально. Код становится предсказуемым, как удар вилкой в глаз.