stdlib additions and deprecations in 1.5 are very good! 👍

Would be nice if extension functions for

Sequence

were annotated with

@Terminal

or something like that to allow easier creation of automated checks for expressions that don't do anything because the developer forgot to call a terminal operation. Me and my team just spent ~2 hours trying to figure out why our code wasn't working after replacing a

forEach

call with

map

. A detekt rule / IntelliJ inspection would help a lot in this case.

message has been deleted

What could go wrong if I'm using

kotlin-stdlib:1.4.32

and

kotlin-reflect:1.3.72

? The compiler tells me strange errors could happen but that doesn't sound very specific. Should I care?

Hello, World! Any official word on if

Result

will be allowed to be returned soon? It's a nice API that we'd like to use, but (unless I'm missing something) currently useless because of this limitation. Just wondering if it's expected to be the case for the foreseeable future.

Hello! Why there are no pow functions for Long an Int?

I suspect this question was asked multiple times, but it gets me every time and I can't google right away: Having a

MutableMap<T, MutableList<R>>

is there a one liner to put an

R

into the existing list OR create a list with a single

R

, something like

// when map is {}
map.magicOp("one", 3) // → { one: [3] }
map.magicOp("one", 4) // → { one: [3,4] }

Would there be any appetite for adding this, as an optimisation to avoid the allocation of a new ArrayList in the current

Iterable<T>.map

method?

public inline fun <T, R> Collection<T>.map(transform: (T) -> R): List<R> {
  return if (this.isEmpty()) emptyList() else (this as Iterable<T>).map(transform)
}

are there plans to merge kotlinx.collections.immutable into the kotlin stdlib or is it just an experiment?

Hi all, I wanted to provide some new samples for the stdlib docs but I was a bit surprised about the hashMapOf example.

val map = hashMapOf<Int, Any?>()
println("map.isEmpty() is ${map.isEmpty()}") // true

map[1] = "x"
map[2] = 1.05
// Now map contains something:
println(map) // {1=x, 2=1.05}

From my understanding the last assert is not general enough as the order of elements is not guaranteed, right? This could maybe be changed to two asserts checking for the two elements separately

what to use instead of the deprecated

String.capitalize()

function?

Unresolved reference: JvmName

, is it necessary the reflect library now? It is a KMP project with Kotlin 1.5.0

Hey. I'm seeing a strange behavior where even though a

Result

is wrapping a failure, the

isSuccess

checks return

true

. The behavior matches the debugger output there. What could be going on?

It looks like compiling

apiLevel=1.3

prevents using

ExperimentalStdlibApi

? Is there a way to still allow that? I'd like to use

String.capitalize(locale: Locale)

which is stable in 1.4 while still making sure I don't use anything that's only 1.4

This may be getting into the multiple receivers feature, but I'm wondering if there's a way to do this without having to wrap the IComponent in a with() call or something similar.

are there any reasons why the documentation of

Sequence#take(…)

does contain code examples only for the

Iterable#take(…)

method and even mentions variants of

take

that do not even exist on

Sequence

? https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.sequences/take.html

is there something like `public fun String.substringAfter(delimiter: String, missingDelimiterValue: String = this)`` that instead returns null if the delimeter is not found?

I am missing 

UByte.toString(radix)

 . Was that forgotten? Or is it missing intentionally? (Kotlin 1.5.10)

Hey folks. Just noticed this issue https://youtrack.jetbrains.com/issue/KT-44867 where

Result.getOrThrow

throw a ClassCastException even if the result is successful. Is there any workaround while the fix is being released. My app depends on it to work properly

Some sort of no-op comparator would be nice for starting a comparator chain.

compareBy

requires to much type info up front, at least the overload that takes a selector.

Hello, World! Am I the only one who finds this is kind of missing?

fun <E> MutableCollection<E>.set(elements: Collection<E>) {
    clear()
    addAll(elements)
}

fun <E> MutableCollection<E>.set(vararg elements: E) = set(elements.asList())

Why is there no flush function in the kotlin.io? I think this is basic enough to be in stdlib.

I'm also a bit surprised that there is .random function, but there is no way to give optional distribution to the function to do some kind of softmax that is imho very useful (at least in ML).

An extension or member to offset an

IntRange

would be super useful. One use case is doing text/string replacement (without or with regexes). Such code:

val offset = -matchResult.range.first
val rangeToReplaceInMatch = (urlGroup.range.first + offset)..(urlGroup.range.last + offset)

could become that one liner:

val rangeToReplaceInMatch = urlGroup.range.offset(-matchResult.range.first)

BTW, I'm doing that in a Kotlin script, where, in a way, adding extra extensions is mostly adding noise to the signal, as scripts are better short for quick understanding.

I would find such a function really useful in stdlib:

inline fun <reified T : Enum<T>> enumValueOfOrNull(value: String): T? =
    enumValues<T>().find { it.toString() == value }
// or
inline fun <reified T : Enum<T>> enumValueOfOrNull(value: String): T? = try {
    enumValueOf<T>(value)
} catch (e: IllegalArgumentException) {
    null
}

what is the difference between ConcurrentMap getOrPut and computeIfAbsent?

i have not seen this done outside of me doing this, since early days of java, where -ea triggers asserts and asserts make for very cheap production debug logging, e.g. removed. the first one logDebug has been my preferred logging apparatus but i just cribbed ".also" as ".debug" is there any other selective #define mechanism extant or planned for the kotlin language?

#!kotlin

fun logDebug(debugTxt: () -> String) {
    try {
        assert(false, debugTxt)
    } catch (a: AssertionError) {
        System.err.println(debugTxt())
    }
}

@ExperimentalContracts
inline fun <T> T.debug(block: (T) -> Unit): T {
    contract {
        callsInPlace(block, InvocationKind.EXACTLY_ONCE)
    }
   try { assert(false)  } catch (a: AssertionError) {
      block(this)
    }
    return this
}

why does the kotlin result class use Throwable for failure instead of making it generic?

Is there a reason why stdlib functions never document the possible exceptions that could be thrown? Maybe a multiplatform thing? I'm looking at https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.io/java.io.-reader/read-text.html and have no clue what to expect on JVM. 🤔