Понимаю. У меня лично претензии больше к тому, что она ругается на методы, которые не могут быть блокирующими. Я совершенно не понимаю, по каким критериям это определяется, ибо там нет ни одного признака.
Там есть конкретный список и блокируемость пропагируется
Тогда становится понятнее. Но работает это настолько же плохо, как торчащий из ByteArrayInputStream проверяемый IOException.
Ну это есть проблема. Единственный способ этого избежать - это тот или иной способ раскраски кода без явных аннотаций и кейвордов. Как я понял, над этим работают, но пока решений нет.
То, что приоритетнее в вашей компании. Синтаксис с = имеет неочевидный сайд-эффект: функция начинает возвращать значение, если результат тела — не Unit. Это в теории может сломать ссылки на методы, не совпадающие по сигнатуре
Начиная с 1.4, методрефы ломаться не будут. Там как раз завезли возможность в качестве функционального типа, возвращающего юнит, передавать методрефы с любым возвращаемым типом.
Начиная с 1.4, методрефы ломаться не будут. Там как раз завезли возможность в качестве функционального типа, возвращающего юнит, передавать методрефы с любым возвращаемым типом.
Вот это отличные новости. Ещё бы ссылки на suspend функции заработали
если нужен Unit, то я всегда explictly указываю его (про сайд эффект), а проблема через = может быть, если длинное выражение какое-то, но не использовать декораторо-подобный синтаксис по мне глупо
в этом примере ещё ок, там действительно вкусовщина, и то, и то выглядит хорошо
но вот писать
fun function() { scope {
} }
вместо
fun function() = scope {
}
странно, потому что это выглядит красиво и убирает индент