История изменений

И как это провялятся в работе?

Ну это уже большая тема. Я думаю, в интернете можно найти подробные статьи, зачем нужны иммутабельные коллекции, вряд ли я смогу в форумном сообщении написать лучше. Вкратце: иммутабельные типы данных (включая коллекции) безопасно передавать между потоками, про них куда проще судить и тд. Банально

val l: List<String> = getSomeList()
val listSize = l.size()
printList(l)
print(l[listSize - 1])

Мне вот непривычно что базовые интерфейсы коллекций (List, Map, Set) имеют только read-only методы kotlin-stdlib/kotlin.collections, но да, сами имплементации это typealias на java коллекции. Только я не понял, чем это плохо, когда ты в своем коде в принципе не можешь модифицировать пришедший List не сделав явный кастинг к чему-то мутабельному, а на такие вещи можно статический анализатор натравить, чтоб в команде не допускать.

В Java-коде нет read-only интерфейсов. Любое взаимодействие с Java-кодом может привести к изменению коллекции. И статический анализатор тут вряд ли поможет. Да и писать код без кастов это какая-то утопия. Я соглашусь, что ситуация не слишком частая, но если есть возможность исключить её в принципе, тем более, что дизайн языка вроде как располагает к этому, непонятно, почему этого не было сделано. Они, конечно, всегда могут их ввести, но когда уже написана куча кода и библиотек, это будет смотреться плохо. Такие базовые кирпичики должны быть в языке с релиза.

PS впрочем я перебарщиваю. Таки опциональный модуль есть: https://github.com/Kotlin/kotlinx.collections.immutable видимо он и станет официальным через какое-то время, поэтому ладно.

И как это провялятся в работе?

Ну это уже большая тема. Я думаю, в интернете можно найти подробные статьи, зачем нужны иммутабельные коллекции, вряд ли я смогу в форумном сообщении написать лучше. Вкратце: иммутабельные типы данных (включая коллекции) безопасно передавать между потоками, про них куда проще судить и тд. Банально

val l: List<String> = getSomeList()
val listSize = l.size()
printList(l)
print(l[listSize - 1])

Мне вот непривычно что базовые интерфейсы коллекций (List, Map, Set) имеют только read-only методы kotlin-stdlib/kotlin.collections, но да, сами имплементации это typealias на java коллекции. Только я не понял, чем это плохо, когда ты в своем коде в принципе не можешь модифицировать пришедший List не сделав явный кастинг к чему-то мутабельному, а на такие вещи можно статический анализатор натравить, чтоб в команде не допускать.

В Java-коде нет read-only интерфейсов. Любое взаимодействие с Java-кодом может привести к изменению коллекции. И статический анализатор тут вряд ли поможет. Да и писать код без кастов это какая-то утопия. Я соглашусь, что ситуация не слишком частая, но если есть возможность исключить её в принципе, тем более, что дизайн языка вроде как располагает к этому, непонятно, почему этого не было сделано. Они, конечно, всегда могут их ввести, но когда уже написана куча кода и библиотек, это будет смотреться плохо. Такие базовые кирпичики должны быть в языке с релиза.

И как это провялятся в работе?

Ну это уже большая тема. Я думаю, в интернете можно найти подробные статьи, зачем нужны иммутабельные коллекции, вряд ли я смогу в форумном сообщении написать лучше. Вкратце: иммутабельные типы данных (включая коллекции) безопасно передавать между потоками, про них куда проще судить и тд. Банально

val l: List<String> = getSomeList()
val listSize = l.size()
printList(l)
print(l[listSize - 1])

Мне вот непривычно что базовые интерфейсы коллекций (List, Map, Set) имеют только read-only методы kotlin-stdlib/kotlin.collections, но да, сами имплементации это typealias на java коллекции. Только я не понял, чем это плохо, когда ты в своем коде в принципе не можешь модифицировать пришедший List не сделав явный кастинг к чему-то мутабельному, а на такие вещи можно статический анализатор натравить, чтоб в команде не допускать.

В Java-коде нет read-only интерфейсов. Любое взаимодействие с Java-кодом может привести к изменению коллекции. И статический анализатор тут вряд ли поможет. Да и писать код без кастов это какая-то утопия. Я соглашусь, что ситуация не слишком частая, но если есть возможность исключить её в принципе, тем более, что дизайн языка вроде как располагает к этому, непонятно, почему этого не было сделано.