BP
все-таки если нужен перф, можно смело писать на джаве, меньше сюрпризов будет
Я очень редко вижу применения takeIf. Если нужен перфоманс то и на джаве код будет ужасен. Я видел код где насильно приводили к Integer заранее
Size: a a a
2020 June 05
BP
Нужно просто понимать во что будет компилироваться код
Y
ну мне не очень понятно зачем делать такие преобразования чтобы проверить if
Y
я конечно понимаю что это некий глобальный механизм написан и там просто забили на проверку примитивов
BP
я конечно понимаю что это некий глобальный механизм написан и там просто забили на проверку примитивов
А что тебе даст проверка на примитив ? У тебя входной тип int а выходной тип Integer. Конечно можно подумать об оптимизации, при наличии :? Делать немного другой иф
Y
в коде вообще нет Integer
AL
я конечно понимаю что это некий глобальный механизм написан и там просто забили на проверку примитивов
Ну тут не сколько проверка примитивов нужна, сколько просмотр выражения дальше. takeIf вернёт nullable тип. Примитив не может быть null.
Y
только примитивы
Y
Ну тут не сколько проверка примитивов нужна, сколько просмотр выражения дальше. takeIf вернёт nullable тип. Примитив не может быть null.
тут согласен, неявное преобразование получается
BP
в коде вообще нет Integer
Integer == Int?
Y
Integer == Int?
код такой
val v = array[0].takeif { it > -1} ?: return
val v = array[0].takeif { it > -1} ?: return
BP
код такой
val v = array[0].takeif { it > -1} ?: return
val v = array[0].takeif { it > -1} ?: return
Ну это не меняет возвращаемый тип функцией takeIf. Повторяюсь в подобных случаях компилятор мог бы оптимизировать
BP
код такой
val v = array[0].takeif { it > -1} ?: return
val v = array[0].takeif { it > -1} ?: return
Просто посмотрите в сгенерированный код
Y
я видел, выглядит как-будто происходит непонятная конвертация
AL
код такой
val v = array[0].takeif { it > -1} ?: return
val v = array[0].takeif { it > -1} ?: return
Ну проблема не меняется, для оптимизации должен сгенериться не тот код, который написан, а тот, который оптимальнее (чтобы takeIf с элвисом оптимально соединялись)
Иначе мы в любом случае имеем то, что takeIf возвращает nullable тип, который точно будет Integer с точки зрения джавы
Иначе мы в любом случае имеем то, что takeIf возвращает nullable тип, который точно будет Integer с точки зрения джавы
Y
теперь я понимаю почему, просто ожидаешь не то что получаешь)
AA
Нет, всё ожидаемо. Просто компилятор не достаточно умный, чтобы понять, что для примитивов результат takeIf не во всех выражениях должен иметь тип Int?
Ну и я с трудом представляю, как это можно заоптимизировать, чтобы не сломать систему типов.
Ну и я с трудом представляю, как это можно заоптимизировать, чтобы не сломать систему типов.
BP
Нет, всё ожидаемо. Просто компилятор не достаточно умный, чтобы понять, что для примитивов результат takeIf не во всех выражениях должен иметь тип Int?
Ну и я с трудом представляю, как это можно заоптимизировать, чтобы не сломать систему типов.
Ну и я с трудом представляю, как это можно заоптимизировать, чтобы не сломать систему типов.
А при чем тут система типов ? Оптимизация вполне может быть аналитической. Компилятор сгенерит более оптимальный код.
AA
А при чем тут система типов ? Оптимизация вполне может быть аналитической. Компилятор сгенерит более оптимальный код.
Так-то да, но тогда выделение части выражения в переменную будет ломать оптимизацию
BP
Так-то да, но тогда выделение части выражения в переменную будет ломать оптимизацию
какие ? у нас банальный if else. Я говорю про
takeif ?: elseValue. В остальных случаях это мало возможно