If you are required to work with ThreadLocals, would that be a good idea or not:

class ThreadlocalDelegate<E>(initializer: ()->E) {
    private val threadLocal = ThreadLocal.withInitial(initializer)

    operator fun getValue(thisRef: Any?, property: KProperty<*>): E {
        return threadLocal.get()
    }

    operator fun setValue(thisRef: Any?, property: KProperty<*>, value: E) {
        threadLocal.set(value)
    }
}

fun <E> threadlocal(initializer: ()->E) = ThreadlocalDelegate(initializer)

fun main() {

    val sdf by threadlocal { SimpleDateFormat("yyyy-MM-dd HH:mm:ss").apply {
        timeZone = TimeZone.getTimeZone("UTC")
    }}

    for(i in 0 until 10 ) {
        thread {
            println("${Thread.currentThread().name} - ${System.identityHashCode(sdf)}) - ${sdf.format(Date())}")
        }
    }

}

Looks like a perfect application of delegates to me!

Not an answer, but some useful info about slack 🙂 ` ``` ` for multi-line code:

There's something simular here: https://stackoverflow.com/questions/45970738/kotlin-delegate-property-by-lazy-that-is-thread-local.

or is it?

How did you do that?

Stylus: https://github.com/openstyles/stylus/wiki

Will look into that, thanks!

Small optimization with extension functions instead,

operator fun <E> ThreadLocal<E>.getValue(thisRef: Any?, property: KProperty<*>): E {
    return get()
}

operator fun <E> ThreadLocal<E>.setValue(thisRef: Any?, property: KProperty<*>, value: E) {
    set(value)
}

fun main() {
    val sdf by ThreadLocal.withInitial { SimpleDateFormat("yyyy-MM-dd HH:mm:ss").apply {
        timeZone = TimeZone.getTimeZone("UTC")
    }}

    for(i in 0 until 10 ) {
        thread {
            println("${Thread.currentThread().name} - ${System.identityHashCode(sdf)}) - ${sdf.format(Date())}")
        }
    }
}

If you want to optimize it, extend

ThreadLocal

, override

initialValue()

and use a

crossinline

lambda there. ;) As for whether it's a good idea - theres a reason why this doesn't exist in the standard library, which is that there is no way to clear the value (cleaning up your resources from the ThreadLocalMap of the thread once you're done) unless you have access to the delegate instance, instead of just the getter. Unless you make the type nullable, but I would advise against that.