Ответ
Platform Type в Kotlin — это тип, который может быть как nullable, так и non-null, и его nullability неизвестна на этапе компиляции. Он возникает при взаимодействии с Java-кодом, где аннотации @Nullable/@NonNull отсутствуют. Обозначается T! (например, String!).
Пример:
// Java-метод
public String getUserName() { ... }
// Kotlin вызов
val name: String? = getUserName() // явно nullable
val name2: String = getUserName() // non-null (риск NPE)Важно:
- Без явного указания типа (
String?/String) компилятор предупредит о неоднозначности. - Всегда аннотируйте Java-код (
@Nullable/@NonNull), чтобы избежать Platform Type.
Ответ 18+ 🔞
Ёпта, слушай, вот есть в Kotlin такая штука — Platform Type. Представь себе хуй с горы: ты не знаешь, упадёт он тебе на голову или пролетит мимо. Вот это оно и есть — тип, который может быть nullable, а может и не быть, и на этапе компиляции нихуя не понятно.
Откуда ноги растут? Из тёмных дебрей Java-кода, где чуваки поленились расставить аннотации @Nullable или @NonNull. Kotlin смотрит на это и говорит: «Ну, ёпта, сам разбирайся». Обозначается это безобразие как T! (типа String!).
Смотри, как это выглядит:
// Допустим, есть Java-метод, написанный каким-то похуистом
public String getUserName() { ... }
// А ты в Kotlin его вызываешь
val name: String? = getUserName() // Тут ты перестраховался, сказал явно: "может быть null"
val name2: String = getUserName() // А тут ты храбрый, считаешь, что не-null. Рискуешь получить NPE прямо в ебало!Важное замечание, блядь:
- Если ты не укажешь тип явно (
String?илиString), компилятор начнёт ныть про неоднозначность. Он не телепат, вротберунчик. - Поэтому золотое правило: всегда, блядь, аннотируй свой Java-код (
@Nullable/@NonNull), чтобы не плодить этих Platform Type'ов. И себе спокойнее, и другим Kotlin-разработчикам, которые будут это использовать, не придётся гадать, какого хуя тут может вылететь. Сам от себя охуеешь потом, когда в три часа ночи будешь искать, почему всё накрылось медным тазом.
