{"id":13274,"date":"2017-12-04T09:20:08","date_gmt":"2017-12-04T08:20:08","guid":{"rendered":"https:\/\/touk.pl\/blog\/?p=13274"},"modified":"2017-12-04T09:20:08","modified_gmt":"2017-12-04T08:20:08","slug":"kotlin-type-inference-puzzler","status":"publish","type":"post","link":"https:\/\/touk.pl\/blog\/2017\/12\/04\/kotlin-type-inference-puzzler\/","title":{"rendered":"Kotlin Type-Inference Puzzler"},"content":{"rendered":"

Kotlin<\/a> takes Type-Inference to the next level (at least in comparison to Java) which is great, but there’re scenarios, in which it can backfire on us.<\/p>\n

<\/p>\n

The Riddle<\/h2>\n
fun foo(int: Int?) = {\n    println(int)\n}\n\nfun main(args: Array<String>) {\n    listOf(42).forEach { foo(it) }\n}<\/pre>\n
And the question is: what does the puzzler()<\/em> method print and why it’s not 42?<\/strong> Assume that the main()<\/em> method gets executed.<\/p>\n
The answer can be found at the very end of the article.<\/p>\n
Explanation<\/h2>\n
In Kotlin, we’ve got not only a local variable type inference (which is also coming to Java<\/a>) but also the return value type inference when writing single-expression methods.<\/p>\n
Which means that if we write a method:<\/p>\n
fun foo() : String  {\n    return \"42\"\n}<\/pre>\n
We can rewrite it using the single-expression method syntax and ignore the explicit type declaration and the return<\/em> keyword:<\/p>\n
fun foo() = \"42\"<\/pre>\n
So, if we have a method:<\/p>\n
fun foo(int: Int?) : Unit {\n    println(int)\n    return Unit\n}<\/pre>\n
we could get rid of the return type declaration, as well as the explicit return<\/em> statement by leveraging single-expression method syntax, right? but we already know that the following doesn’t work:<\/p>\n
fun foo(int: Int?) = {\n    println(int)\n}<\/pre>\n
The devil’s in the details but everything becomes crystal clear if we specify the return type explicitly:<\/p>\n
fun foo(int: Int?) : () -> Unit = {\n    println(int)\n}<\/pre>\n
If we look closely, it can be seen that we mixed two approaches here and actually defined a method that doesn’t return Unit<\/em> but a () -> Unit<\/em> itself – which is simply an action that doesn’t accept any parameters and doesn’t return anything<\/em> – which is semantically equivalent to returning a java.lang.Runnable<\/em> instance.<\/p>\n
This is because Kotlin utilizes curly braces not only for defining classes\/methods but also for defining Lambda Expressions and\u00a0{ println(42) }<\/em> is a valid Lambda Expression declaration:<\/p>\n
val foo: () -> Unit = { println(42) }<\/pre>\n
So, our original example is simply a Higher-Order Function<\/a> accepting an Int<\/em> parameter and returning a function that prints it – when we return it in the forEach()<\/em>\u00a0the return value just gets ignored.<\/p>\n
So, if we want to fix our example, we have two ways to go.<\/p>\n
Explicitly call invoke() on the returned function:<\/p>\n
listOf(42)\n  .forEach { foo(it).invoke() }<\/pre>\n
or simply define the method properly by removing the “=<\/em>” sign:<\/p>\n
fun foo(int: Int?) {\n    println(int)\n}<\/pre>\n
or by leveraging the single-expression method syntax:<\/p>\n
fun foo(int: Int?) = println(int)<\/pre>\n
That’s why I encourage my fellow team members to declare return types explicitly.<\/p>\n
Code snippets can be found on GitHub.<\/a><\/p>\n
Answer<\/h3>\n
The method prints nothing.<\/p>\n","protected":false},"excerpt":{"rendered":"Kotlin takes Type-Inference to the next level (at least in comparison to Java) which is great, but there’re…\n","protected":false},"author":68,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":{"0":"post-13274","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-development-design"},"_links":{"self":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts\/13274","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/comments?post=13274"}],"version-history":[{"count":1,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts\/13274\/revisions"}],"predecessor-version":[{"id":13275,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts\/13274\/revisions\/13275"}],"wp:attachment":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/media?parent=13274"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/categories?post=13274"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/tags?post=13274"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}