I might be misusing

run()

. I tend to use it in cases where I would combine

let()

and `with()`…

small thing: may we introduce

pathOf(String/URI)

?

Indeed @gaetan. Does kotlin-

log

at least provide

e

as default for the base? Because if so users could keep using

log

as natural logarithm. LIke in python https://docs.python.org/2/library/math.html#math.log or R http://astrostatistics.psu.edu/su07/R/html/base/html/Log.html

Currently "containers" (in general) in Kotlin are just library classes. There's nothing "special" about them. On one hand, it gives additional flexibility - like, you can potentially have containers with side effects in container operations. On the other hand, compiler (and JIT) can't perform optimizations that, for example, skip some operations (like creating an intermediate container), or change evaluation order. Since most collection operations work with abstract collections, you can't do such optimizations "in general". We have some ongoing discussion about collection literals & loop fusion (you'd usually call that "deforestation" in functional context). In 1.4 scope, maybe.

could we always resolve

x += y

with

plusAssign

and

x + y

with

plus

? It's really a pity to give up on that because of ambiguity

I finally got annoyed enough to create an issue about the name: https://github.com/DemonWav/kotlin-utils/issues/1

That's actually where I found the library.

Remains the discussion if exceptions thrown by close during exception handling should be `addSuppressed`or silently ignored. Any one knows, why the author of

use {}

decided to ignore them?

I'd link to your comment here from #general.

val Class<*>.boxed
	get() =
		if (isPrimitive)
			when (this) {
				Boolean::class.java -> java.lang.Boolean::class.java
				Char::class.java -> java.lang.Character::class.java
				Byte::class.java -> java.lang.Byte::class.java
				Short::class.java -> java.lang.Short::class.java
				Int::class.java -> java.lang.Integer::class.java
				Long::class.java -> java.lang.Long::class.java
				Float::class.java -> java.lang.Float::class.java
				Double::class.java -> java.lang.Double::class.java
				Void.TYPE -> java.lang.Void::class.java
				else -> error("Unexpected primitive class: $this")
			}
		else
			this


fun Class<*>.isAssignableOrBoxableTo(otherClass: Class<*>) =
	otherClass.isAssignableOrBoxableFrom(this)


fun Class<*>.isAssignableOrBoxableFrom(otherClass: Class<*>) =
	boxed.isAssignableFrom(otherClass.boxed)

🤔 Would that be useful for stdlib?

actually i'm not even sure it should exist

When writing an API is there a way to finetune via annotations for which method parameters the user should get parameter hints in in intellij?

I think there is a typo in kotlindoc for

trimStart()

, it shouldn't say " and trailing". https://github.com/JetBrains/kotlin/blob/1.1.60_173/libraries/stdlib/src/kotlin/text/Strings.kt#L106 https://github.com/JetBrains/kotlin/blob/1.1.60_173/libraries/stdlib/src/kotlin/text/Strings.kt#L111

@dave @raulraja Thanks for the support. I’ve filed https://youtrack.jetbrains.com/issue/KT-21426

I wish Kotlin returned

A?

in those types of operations that throw exceptions because the only possible error in that context is being out of range.

so, i just asked this in general, but i see this the questions here are related… is there any commonly-used library, that’s like “kotlin: the missing bits” that extends the stdlib with various convenience functions that perhaps haven’t yet made it into the stdlib?

one thing that I think may be source of bug about ranges is that

0 until x

is

[0, x)

, but

x downTo 0

is

[x, 0]

Another related issue, a while ago I was looking for something

x to y

that returns a sequence that goes into whatever direction is required, for example:

0 to 5

is

[0,1,3,4]

and

0 to -5

is

[0,-1,-2,-3,-4]

.

There isn’t anything like that in stdlib AFAIK. A simple extension like this (end inclusive) should suffice though

infix fun Int.through(end: Int): IntProgression {
    return if (end > this) this..end else this downTo end
}

fun main(args: Array<String>) {
    (0 through 5).forEach(::println)
    (4 through -3).forEach(::println)
}

Whatever happened to kotlinx persistent collections? Last I heard, there was some talk about them not implementing the collection interfaces to fix the operator overload problem, I think... looks like the repo hasn't moved in some time https://github.com/Kotlin/kotlinx.collections.immutable

I’ve implemented it as a sequence wrapper. Is there interest in including it in the stdlib? If so i can send in a PR

Hi, why bitwise operations on

Byte

and

Short

are marked as experimental in the stdlib?

it's for multiplatform projects to link against

I doesn't find Random class or Time Manipulation API on stdlib. For the moment stdlib is very small.

@voddan if they are going to be cross platform would the JVM one based in the JDK classes or are these complete new implementations?

https://xkcd.com/927/ comes to mind.

is there a discussion about including a

fun java.io.Reader.asCharSequence(decoding: Charset = Charsets.UTF_8)): Sequence<Char>

--or other wrappers on

<http://java.io|java.io>

classes in the std-lib?

Is there an ETA for Kotlin immutable collections or is that on hold?

Is there any particular reason there is no

toMap()

function available as an extension on a collection of

Map.Entry<K, V>

?