Что такое оператор to в Kotlin и как он используется

Что проверяют

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

Как отвечать

to это infix-расширение: public infix fun <A, B> A.to(that: B): Pair<A, B>. Запись "a" to 1 это вызов функции на получателе, который создаёт Pair.

val config = mapOf("retries" to 3, "timeoutMs" to 5000)
for ((key, value) in config) log(key, value)

Что стоит добавить:

• элементы пары называются first и second. Ключом и значением они становятся только по смыслу использования, например внутри mapOf;
• пара раскладывается через деструктуризацию, потому что у неё объявлены component1 и component2;
• приоритет infix-вызова ниже арифметики, поэтому 1 to 2 + 3 даёт пару из единицы и пятёрки. Скобки тут дешевле спора;
• любой может объявить свою infix-функцию, ничего магического в to нет;
• каждая пара это отдельный объект, и для примитивов добавляется упаковка. Там, где карта собирается в горячем пути, дешевле buildMap с вызовами put.

Android-нюанс: to всегда возвращает kotlin.Pair, а часть платформенных API ждёт android.util.Pair или его вариант из androidx. Путаница в импортах тут даёт ошибку компиляции на ровном месте.

Где спотыкаются

Называют to оператором и не могут сказать, где он объявлен. Следом обычно не удаётся объяснить, почему рядом работает until или downTo, хотя это ровно такие же функции.

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

Тянут Pair в публичный API вместо именованного типа. Сигнатура с парой ничего не говорит о смысле полей, и через месяц никто не помнит, что лежит первым, а отладка идёт по номерам.