Комментарии 9
Такими темпами, Kotlin обойдет Scala по всем статьям лет за 5.
Медленно, но верно движутся к светлому будущему. А лайтбенд че то топчется на месте…
Медленно, но верно движутся к светлому будущему. А лайтбенд че то топчется на месте…
Интересно, а компилятор проверит, что обещания контракта метод действительно выполняет или примет их на веру?
Пока неизвестно, как оно будет, но контракт ведь пишет разработчик для конкретного метода. Возможно, выполнение этого контракта тоже будет лежать на совести разработчика.
Вот на совести разработчика — это сделает язык дырявым. Простой пример:
fun test() {
val x: String
run { x = "Hello" }
println(x.length)
}
fun <R> run(block: () -> R): Unit {
contract {
callsInPlace(block, EXACTLY_ONCE)
}
//return block() бугагашечка
}
В результате, если мы поверили контракту, но не проверили его, то в методе test()
мы получаем обращение к неинициализированной локальной переменной — то, чего, например, в Java не может быть никогда и ни за что.
На самом деле даже если контракты проверяются при компиляции, не забываем, что компиляция раздельная. Если метод run
в прекомпилированном классе, и мы там подхачили контракт руками, мы получим тот же эффект. Опасной мне кажется эта фича, в общем. Может, конечно, разработчики умнее меня и как-то всё предусмотрели...
Дело может оказаться даже не в самой возможности проверки, а в том, что такие проверки могут быть очень дорогими для компилятора, что значительно увеличит время сборки проекта. Если разработчик покроет много методов контрактами, то само извлечение метаинформации уже будет дороговато, а если добавить и проверку выполнимости контракта…
Они не стопроцентно работают, их можно обмануть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Текущая разработка Kotlin