Kotlin Type-Inference Puzzler

Kotlin 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.

The Riddle

fun foo(int: Int?) = {

fun main(args: Array<String>) {
    listOf(42).forEach { foo(it) }

And the question is: what does the puzzler() method print and why it’s not 42? Assume that the main() method gets executed.

The answer can be found at the very end of the article.


In Kotlin, we’ve got not only a local variable type inference (which is also coming to Java) but also the return value type inference when writing single-expression methods.

Which means that if we write a method:

fun foo() : String  {
    return "42"

We can rewrite it using the single-expression method syntax and ignore the explicit type declaration and the return keyword:

fun foo() = "42"

So, if we have a method:

fun foo(int: Int?) : Unit {
    return Unit

we could get rid of the return type declaration, as well as the explicit return statement by leveraging single-expression method syntax, right? but we already know that the following doesn’t work:

fun foo(int: Int?) = {

The devil’s in the details but everything becomes crystal clear if we specify the return type explicitly:

fun foo(int: Int?) : () -> Unit = {

If we look closely, it can be seen that we mixed two approaches here and actually defined a method that doesn’t return Unit but a () -> Unit itself – which is simply an action that doesn’t accept any parameters and doesn’t return anything – which is semantically equivalent to returning a java.lang.Runnable instance.

This is because Kotlin utilizes curly braces not only for defining classes/methods but also for defining Lambda Expressions and { println(42) } is a valid Lambda Expression declaration:

val foo: () -> Unit = { println(42) }

So, our original example is simply a Higher-Order Function accepting an Int parameter and returning a function that prints it – when we return it in the forEach() the return value just gets ignored.

So, if we want to fix our example, we have two ways to go.

Explicitly call invoke() on the returned function:

  .forEach { foo(it).invoke() }

or simply define the method properly by removing the “=” sign:

fun foo(int: Int?) {

or by leveraging the single-expression method syntax:

fun foo(int: Int?) = println(int)

That’s why I encourage my fellow team members to declare return types explicitly.

Code snippets can be found on GitHub.


The method prints nothing.

You May Also Like

OSGi Blueprint visualization

What is blueprint?Blueprint is a dependency injection framework for OSGi bundles. It could be written by hand or generated using Blueprint Maven Plugin. Blueprint file is only an XML describing beans, services and references. Each OSGi bundle could hav...

Phonegap / Cordova and cross domain ssl request problem on android.

In one app I have participated, there was a use case:
  • User fill up a form.
  • User submit the form.
  • System send data via https to server and show a response.
During development there wasn’t any problem, but when we were going to release production version then some unsuspected situation occurred. I prepare the production version accordingly with standard flow for Android environment:
  • ant release
  • align
  • signing
During conduct tests on that version, every time I try to submit the form, a connection error appear. In that situation, at the first you should check whitelist in cordova settings. Every URL you want to connect to, must be explicit type in:
If whitelist looks fine, the error is most likely caused by inner implementation of Android System. The Android WebView does not allow by default self-signed SSL certs. When app is debug-signed the SSL error is ignored, but if app is release-signed connection to untrusted services is blocked.


You have to remember that secure connection to service with self-signed certificate is risky and unrecommended. But if you know what you are doing there is some workaround of the security problem. Behavior of method
must be changed.

Thus add new class extended CordovaWebViewClient and override ‘onReceivedSslError’. I strongly suggest to implement custom onReceiveSslError as secure as possible. I know that the problem occours when app try connect to example.domain.com and in spite of self signed certificate the domain is trusted, so only for that case the SslError is ignored.

public class MyWebViewClient extends CordovaWebViewClient {

   private static final String TAG = MyWebViewClient.class.getName();
   private static final String AVAILABLE_SLL_CN
= "example.domain.com";

   public MyWebViewClient(DroidGap ctx) {

   public void onReceivedSslError(WebView view,
SslErrorHandler handler,
android.net.http.SslError error) {

String errorSourceCName = error.getCertificate().

       if( AVAILABLE_SLL_CN.equals(errorSourceCName) ) {
           Log.i(TAG, "Detect ssl connection error: " +
error.toString() +
„ so the error is ignored”);


       super.onReceivedSslError(view, handler, error);
Next step is forcing yours app to  use custom implementation of WebViewClient.

public class Start extends DroidGap
   private static final String TAG = Start.class.getName();

   public void onCreate(Bundle savedInstanceState)
       super.setIntegerProperty("splashscreen", R.drawable.splash);

       MyWebViewClient myWebViewClient = new MyWebViewClient(this);

// yours code

That is all ypu have to do if minSdk of yours app is greater or equals 8. In older version of Android there is no class
So in class MyCordovaWebViewClient class there are errors because compliator doesn’t see SslError class. Fortunately Android is(was) open source, so it is easy to find source of the class. There is no inpediments to ‘upgrade’ app and just add the file to project. I suggest to keep original packages. Thus after all operations the source tree looks like:

Class SslError placed in source tree. 
 Now the app created in release mode can connect via https to services with self-signed SSl certificates.