Vsevolod Tolstopyatov
Vsevolod Tolstopyatov
@sandwwraith that's up to being designed (by default, I guess it's ok not to support them), but plugin definitely not supposed to crash with StackoverflowError
I would suggest re-opening the issue. It might be the case that `values` reading is performance-sensitive and expected to be GC-free. If we see that it's actually the case (e.g....
@qurbonzoda you can probably take a look at https://github.com/Kotlin/kotlinx.coroutines/blob/master/buildSrc/src/main/kotlin/Java9Modularity.kt to save an effort
Could you please elaborate on why you need a separate implementation though?
@fzhinkin is currently unavailable. Filesystem support (which includes extending metadata beyond what we are providing currently) is part of our [stabilization roadmap](https://github.com/Kotlin/kotlinx-io/milestone/5), and high chance this request will be incorporated...
It seems like we need a proper inspection or compiler diagnostic here. `AtomicRef` is as dangerous and tricky as Java's `AtomicReference` -- it leaks the fact that boxed integer values...
Posted the solution internally, re-posting here: ``` public fun atomic(initial: T): AtomicRef = atomic(initial, TraceBase.None) public fun atomic(initial: Int): AtomicInt = atomic(initial, TraceBase.None) @JvmName("atomicInt") @Suppress("FINAL_UPPER_BOUND") public fun atomic(initial: T): AtomicInt...
It would be nice to do it in 1.9.20 scope, but taking into account, it's a library-level change, it worth returning to it after all Kotlin-repo-related changes are merged. Feel...
Indeed. The moment we deprecate it, we'll see the proper demand and will act accordingly, depending on our constraints. The poor man's [initial] replacement is to copy-paste `SyncrhonizedObject.kt` into your...
Well, it can be put after the main message. The problem with the current one is that it first explains *where* things went wrong instead of *what* went wrong