fun addStatement(statement: Statement?){
	statement?.let{
		statements.add(it)
	}
}

or less indentation

fun addStatement(statement: Statement?){
	statement?:return
	statements.add(statement)
}

or just old reliable

fun addStatement(statement: Statement?){
	if(statement != null)
		statements.add(statement)
}

4️⃣

fun addStatement(statement: Statement?) {
    statement?.let(statements::add)
}

3 and 5 generate absolutely the smallest, equivalent bytecode, followed by 2. 1 and 4 are showing artifacts of the inliner and the implementation of function references, but it would be interesting to know how they JIT - I would suspect all 5 compile to the same native code, depending on platform.

2:

L0
    LINENUMBER 11 L0
    ALOAD 0
    DUP
    IFNULL L1
    GOTO L2
   L1
    LINENUMBER 11 L1
    POP
    RETURN
   L2
    POP

5:

L0
    LINENUMBER 24 L0
    ALOAD 0
    IFNONNULL L1
    RETURN

It's weird that the compiler does 2 in such a convoluted way.

Yeah, the stack and local gymnastics most of these display are byproducts of the compilation.

It's caused by the

DUP

and

POP

. I find it weird they are placed there in the first place and the first non-control flow op executed afterwards is always a

POP

None of the above. The signature should be

fun addStatement(statement: Statement){
	// ...
}

And don't call the method if you don't have a statement. Thats the nice thing in kotlin, you can control your api in relation to null! 🙂