Обновить
88
Андрей Бреслав@abreslav

Co-founder @ Alter (psyalter.ru), Ex-Kotlin

154
Подписчики
Отправить сообщение

Пожалуйста, записывайте волнующие вас проблемы (особенно "практически виснущий" компилятор) в наш баг-трекер: https://youtrack.jetbrains.com/issues/KT

Для этих целей в 1.1 появилась аннотация @PublishedApi, применимая к internal-декларациям

Ну вы, наверное, заметили, что у этих штук разные типы :)

Хочу заметить, что это все — внутренние особенности компилятора, и мы не гарантируем, что они будут поддерживаться в будущем :)

Этот пост — уже часть истории. Вопросы можно задать у нас в Слэке (http://slack.kotlinlang.org/) или в форуме (https://discuss.kotlinlang.org/)

Слухи — они на то и слухи :)

Как можем, лоббируем. Если есть претензии — работаем :)

Источник этого слуха (тут) не заслуживает доверия.

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

Для справки: kotlin.Map и так существует, и мы с Вами говорим именно о нем. Поддержка его в синтаксисе, возможно, будет, но как это связано с темой разговора, я пока не очень понимаю.
Это различия на уровне синтаксиса, иначе не было бы никакого интеропа. (Отмечу, что заменить один класс на другой и добавить существующему классу новый суперкласс — это не одно и то же :))
Потому что в Java Map не реализует интерфейс Collection, и у нас нет никакой возможности его заставить это делать (и нигде более в языка мы ничего подобного не делаем, а когда пытались, получались ошибки во время выполнения). Придумать более подробный ответ я не смог, задайте уточняющий вопрос, если есть какое-то надопонимание.

Кстати, int[] и IntArray — это одно и то же решение, то есть специальный тип для массива примитивов, только синтаксис разный.
Не вижу связи с коллекциями
Как, по-вашему, мы выкрутились с массивами? :)
В принципе, такая возможность есть, но будет очень пестро
Такова реальность JVM: от финального класса наследоваться нельзя, и делегироваться к классу тоже в общем случае нельзя
Это сложилось исторически: когда-то синтаксис аннотаций и модификаторов был одинаковый, поэтому подсветку тоже сделали одинаковую. С тех пор синтаксис изменился, цвета остались, все привыкли, и Вы первый, кто обратил на это внимание за последние полгода :)
Возможна, но на лямбдах она будет обрываться, что как бы теряет смысл.
На сегодня таких ворнингов у нас нет. И они в любом случае не будут корректно работать с лямбдами
Java, Groovy, Scala, C#, ML, F#, Gosu, Python, etc

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

Замечу, что у нас тут не С++, и на собеседовании про инкремент спросить особо нечего. Разве что разницу между префиксным и постфиксным.

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Зарегистрирован
Активность