JakeWharton

import java.util.Arrays;

class NonCapturing {
  public static void main(String... args) {
    run(new Runnable() {
      @Override public void run() {
        System.out.println("Hey!");
      }
    });
  }

elizarov

class Result<T> private constructor(private val result: Any?) {
    // discovery

    val isFailure: Boolean get() = result is Failure
    val isSuccess: Boolean get() = result !is Failure

    // value retrieval

    fun get(): T =
        if (result is Failure) throw result.exception

makiftutuncu

import scala.util.Try

implicit class KotlinLikeExtensions[A](a: => A) {
  /**
    * Produce a new value using current value
    */
  def let[B](f: A => B): B = f(a)

  /**
    * Do something with current value and produce nothing

cretz

Kotlin Annoyances

These are things that I found annoying writing a complex library in Kotlin. While I am also a Scala developer, these should not necessarily be juxtaposed w/ Scala (even if I reference Scala) as some of my annoyances are with features that Scala doesn't even have. This is also not trying to be opinionated on whether Kotlin is good/bad (for the record, I think it's good). I have numbered them for easy reference. I can give examples for anything I am talking about below upon request. I'm sure there are good reasons for all of them.

1. Arrays in data classes break equals/hashCode and ask you to overload it. If you are going to need to overload it and arrays have no overridability, why not make the least-often use case (the identity-comparison equals) the exception?

felipecsl

private fun <T> mutableLazy(initializer: () -> T) = Delegate(lazy(initializer))

class Delegate<T>(private val lazy: Lazy<T>) {
  private var value: T? = null

  operator fun getValue(thisRef: Any?, property: KProperty<*>): T {
    return value ?: lazy.getValue(thisRef, property)
  }

  operator fun setValue(thisRef: Any?, property: KProperty<*>, value: T) {