М
Зато круто, когда это семантически подходит. Увы, разграничить эти два случая не представляется возможным.
Всегда можно дописать operator fun JavaType.set(...)
Size: a a a
2020 January 29
AN
Ну не нравится, не используйте. Интероп же
М
Ну не нравится, не используйте. Интероп же
Я чисто поныть
OY
А раньше тоже такие статьи были?
https://blog.jetbrains.com/kotlin/2020/01/ktor-1-3-release/
https://blog.jetbrains.com/kotlin/2020/01/ktor-1-3-release/
BP
А раньше тоже такие статьи были?
https://blog.jetbrains.com/kotlin/2020/01/ktor-1-3-release/
https://blog.jetbrains.com/kotlin/2020/01/ktor-1-3-release/
ну релиз покотлину да, ктора не видел
OY
ну релиз покотлину да, ктора не видел
я именно про ktor конечно же
AN
я именно про ktor конечно же
Они сильно активизировались с выходом спейса
BP
А раньше тоже такие статьи были?
https://blog.jetbrains.com/kotlin/2020/01/ktor-1-3-release/
https://blog.jetbrains.com/kotlin/2020/01/ktor-1-3-release/
хороший релиз
BP
серелизация колекций в клиенте очень не хватало)
VP
А раньше тоже такие статьи были?
https://blog.jetbrains.com/kotlin/2020/01/ktor-1-3-release/
https://blog.jetbrains.com/kotlin/2020/01/ktor-1-3-release/
Интересно, зачем было совместимость ломать, если можно было бы сделать
close() no-op и задепрекейтить его 🤔VP
Видимо, потому что из-за kotlinx.io всё равно совместимость сломана.
Как-то неожиданно такое после 1.0
Как-то неожиданно такое после 1.0
OY
Интересно, зачем было совместимость ломать, если можно было бы сделать
close() no-op и задепрекейтить его 🤔мне кажется осознанно, чтобы пользователи зарефакторили код, где реально нужен
close()OY
We’ve found a lot of cases where someone had forgotten to close the HttpResponse, even in simple examples, and got memory leaks because of it. - я об этомVP
We’ve found a lot of cases where someone had forgotten to close the HttpResponse, even in simple examples, and got memory leaks because of it. - я об этомНу так эта проблема фиксится тем, что теперь ответ в памяти и не держит соединение
BP
Видимо, потому что из-за kotlinx.io всё равно совместимость сломана.
Как-то неожиданно такое после 1.0
Как-то неожиданно такое после 1.0
как раз норм, хотя версия минорная, но лучше поломать в начале, чем тащить его дальше (легаси)
BP
можно сделать просто заглушку close + деприкейт error
OY
Ну так эта проблема фиксится тем, что теперь ответ в памяти и не держит соединение
тогда можно попробовать спросить @LeonidStashevsky :)
LS
Если выкачивать response в память - мы не сломали бы код, но поломали runtime тем у кого стриминг. Молча летел бы OOM
A
это баг или фича? 😄
https://pl.kotl.in/siCrRdx1G
Exception in thread "main" java.lang.ClassCastException: java.lang.Boolean cannot be cast to kotlin.Unit
at FileKt.crashFun (File.kt:15)
at FileKt.main (File.kt:9)
at FileKt.main (File.kt:-1)
fun main() {
println("Hello, world")
crashFun()
}
fun crashFun() {
@Suppress("test")
if (Math.random() > -1) {
if (Math.random() < -1) {
var x = 10
} else {
Math.random() > 0.1
}
}
}https://pl.kotl.in/siCrRdx1G
Exception in thread "main" java.lang.ClassCastException: java.lang.Boolean cannot be cast to kotlin.Unit
at FileKt.crashFun (File.kt:15)
at FileKt.main (File.kt:9)
at FileKt.main (File.kt:-1)
АЗ
Серьезно?