Hello everybody. I think I have found a gap in the koltin stlib and I would like to make a contribution to it. But first I would like to discuss it with you to be sure it is worthwhile. A few days ago, a student asked me for help to find an efficient algorithm in kotlin to solve this exercise https://www.hackerrank.com/challenges/fraudulent-activity-notifications/problem . After analyzing it, I realized that it is necessary to use a collection such that: - it is mutable - it has random/direct access (read-only) - it keeps the elements sorted at all times (invariant) - it can have duplicate elements I started looking for data structures in the kotlin and java stlib and did not find any that met the requirements. I searched stackoverflow and found this thread https://stackoverflow.com/questions/8725387/why-is-there-no-sortedlist-in-java. None of the alternatives work to solve the exercise efficiently. So I implemented the data structure myself and solved the exercise. Personally I think it is worthwile because the hackerrank problem seems to me to be a likely scenario in the fintech domain. What do you think?

Hi all, whats the stdlib way to achieve this?

val actual = listOf("a","b","c","d")
val expected = listOf("ab","bc","cd")

I’m surprised by the definition of

fun <T, R> T.runCatching(block: T.() -> R): Result<R>

- it catches

Throwable

, and hence

Error

, including things you almost certainly don’t want to catch like

OutOfMemoryError

. It also makes no attempt to propagate

InterruptedException

(or reset the interrupted status of the Thread when catching it). Am I missing something? Or just woefully out of date in my JVM exception handling?

Anyone else thinks it would be nice to have a

String.prepend(value: String)

in the stdlib? I need it quite often and

.let { "prefix$it" }

doesn't express intent so well.

Hi all, whats the best way to achieve this?

val actual = listOf(
  Item(type = A, value = 1),
  Item(type = B, value = 2),
  Item(type = B, value = 3)
)

val expect = mapOf(
  A to listOf(Item(type = A, value = 1)),
  B to listOf(Item(type = B, value = 2), Item(type = B, value = 3)),
  C to emptyList()
)

Probably this is a super FAQ, but if another module in my project has

data class Value(val foo: Foo?)

and I do

if (value.foo != null) foo.bar() else doStuff()

, there's an error "smart cast is impossible". But if I know that a) it's val b) no multithreading is used, can I "smarten" the compiler? Perhaps by adding some

contract

somewhere? Is there a YouTrack issue along these lines maybe?

❓ Has the cost of using lazy on the JVM changed at all since at Google in 2019? The gist of this talk is to warn developers against using

lazy

(and possible other Property Delegation) - the foundation of their argument appears to be that use of reflection in property delegation is too costly for most use cases. Unfortunately they don't give any examples of where the 'tipping point' of complexity lies; where

lazy

does become worth it. This has put my team off from using lazy even for cases where moderately complex objects are being created. I'm suspect of two things in this talk: firstly their poor choice of example - obviously it's going to be inefficient to use this to allocate an

Int

, but what about smaller-to-moderately sized classes? No benchmarks provided or discussion of initial

lazy

cost vs. subsequent

lazy

where presumably some aspects of any reflection would have become cached. Thoughts?

Hello! Is there builtin solution to check for overflow when converting Long.toInt() ?

why does

List

have

chunked()

but

DoubleArray

does not?

Why does the call to sendUser2() throw a compiler error?

value class UserId(private val value: Int)

fun sendUser1(userId: UserId) = ...
fun sendUser2(userId: Int) = ...

// Compiler error: required: UserId, found: Int. Makes sense because an Int isn't always a UserId.
sendUser1(1)

// Compiler error: required: Int, found: UserId. Does not make sense because a UserId is always an Int.
sendUser2(UserId(1))

Why doesn't the compiler see that type UserId is of type Int? It makes it harder for a project to adopt value classes if the new types aren't compatible with it's super type

Navigating through stdlib code I found one function annotated like this:

@Suppress("EXTENSION_SHADOWED_BY_MEMBER") // false warning, extension takes precedence in some cases

Does anyone know in which cases the extension takes precedence? This one is

Collection<T>.containsAll(elements: Collection<T>)

for instance.

IntRange

and similars have methods to easily extract collections.

ClosedRange

instead no.. this is a pity

Hello. Does anyone know the justification for kotlin.io being a set of extensions to

java.io.File

instead of

java.nio.file.Path

? I assume this is to do with the legacy Java 1.6 support but it's quite awkward for programs that want to benefit from the NIO features like in-memory file systems, etc.

I can't find anything in YouTrack about this and was wondering if there are any plans to switch the implementation to using

java.nio.file.Path

and then leave the current methods as forwarders that convert the File to a Path.

Not a problem but a mere curiosity; is there any more 'first class' way of writing

{ it }

where for a single parameter lambda that merely pipes-through its input value?

message has been deleted

I just discovered that the Byte and Short classes (and their unsigned counterparts) have no

shl

or

shr

infix functions. Is this intentional or not?

Crosspost: https://kotlinlang.slack.com/archives/C0B9K7EP2/p1634034253030700

I am looking at removing java date/time from my code where it is almost painless. in the matter of java

Instant

ctor, and serialization, we need 12 bytes, a long for ms and int for nanos. The kotlin

Duration

analog class only appears to support at best a Long or Double, neither which supports the same resolution. Instead of a break between Java's Date, DateTime, and Instant classes which supports DateTimes with nanosecond backingstores, Duration apparently presumes to do all three and for events on astronomical scales of time resolution appears to force the coder to box a relative 64 bit expanse of measurement for the non-jvm stdlib. to my understanding BigInteger math is a sliding set of 32 bit Int operations going up and down to MAXINT resolution and is claimed to be faster in the C2 on intel than native wide instructions in some cases. Is Duration with a promotion option to BigInteger backingstore reasonable? The solution would address a) usecases that want higher res, and b) a sideload BitSet/BigInt serialization option that can match impedences with e.g. Instance and other DateTime libraries which don't all apparently assume 64 bits and only 64 bits.

Are

maxBy

and

minBy

going to be un-deprecated in 1.6 with a new strict behaviour? Or is it planned for a later version?

what about changing on

Map<K, V>

the

getOrElse

by passing as argument the key which wasn't found?

public inline fun <K, V> Map<K, V>.getOrElse(key: K, defaultValue: () -> V): V

to

public inline fun <K, V> Map<K, V>.getOrElse(key: K, defaultValue: (V) -> V): V

My use case is to search for the same key somewhere else

What would you think about an indexed

Sequence.takeWhile

? E.g. one of these:

fun <T>Sequence<T>.takeThenWhile(count: Int, predicate: (T) -> Boolean): Sequence<T> {
    var i = 0
    return this.takeWhile{ i < count || predicate(it) }.onEach { i++ }
}


fun <T>Sequence<T>.takeWhileIndexed(predicate: (Int, T) -> Boolean): Sequence<T> {
    var i = 0
    return takeWhile { predicate(i, it) }.onEach { i++ }
}

Both

take

and

takeWhile

could be implemented in terms of this function

fun <T>Sequence<T>.take(count: Int) = takeThenWhile(count) { false }
fun <T>Sequence<T>.takeWhile(predicate: (T) -> Boolean) = takeThenWhile(0, predicate)

fun <T>Sequence<T>.take(count: Int) = takeWhileIndexed { i, _ -> i < count }
fun <T>Sequence<T>.takeWhile(predicate: (T) -> Boolean) = takeWhileIndexed { _, t -> predicate(t) }

partition

only supports two outputs. What about adding something like this to the stdlib?

/**
 * Similar to the stdlib partition method, but supports an arbitrary number of output lists. The number
 * of outputs must be known in advance.
 */
@Throws(IndexOutOfBoundsException::class)
fun <T> List<T>.partitionInto(size: Int, predicate: (T) -> Int): List<List<T>> {
  val lists = listOf(*(0.until(size).map { mutableListOf<T>() }.toTypedArray()))
  for (element in this) {
    val index = predicate(element)
    lists[index].add(element)
  }
  return lists
}

uhh, has there been any discussion about using something like

inline class

to simplify java's`compareTo` function? I was thinking that an

inline class

that's wrapping the results would be handy and do a lot for readability. If not, can we

typealias ComparisonResult = Int

and put some docs there? I feel like kotlin can do a lot to add sugar and/or lipstick to this pig in java.

Is there a function in the kotlin stdlib to split a list into a list of sublists with a predicate to choose where to separate each sublist, and where the result preserves the order of elements.

List::chunked

doesn’t do what I want, nor does

List::windowed

.  E.g. if I have a list, x = [“a”, “b”, “C”, “d”, “E”, “F”, “g”] and I want to split it into sublists where the case is the same within the sublist, I could pass in a predicate to this function something like…

x.split { x, b -> a.isUpperCase() != b.isUpperCase() }

giving me:

[["a", "b"], ["C"], ["d"], ["E", "F"], ["g"]]

I often need this operation, but always end up writing it with imperative code.  Is there something in the stdlib I’m missing.

Hi, I see that

.capitalize()

is be replaced by

.replaceFirstChar()

but the latter one is not shown in my IDE? I only got

replaceFirst

Currently we have

enumValues<T>(): Array<T>

and

enumValueOf<T>(name: String): T

for enums. It would be nice if there was also

enumValueAt<T>(ordinal: Int): T

. It's pretty easy to work around with

enumValues()[ordinal]

, so not a huge deal, but it feels a bit clunky. Another nice to have for would be something like

enumSize<T>(): Int

. Again, easy to work around with

enumValues().size

, but same argument as above.

Just of curiosity: Why is

ceil()

not an extension on Double?

joinToString

has

truncated: CharSequence = "..."

as an optional parameter. It would be nice if

String.take(n: Int)

could have the same optional parameter that is appended in case

n

is smaller than the length of the String. Maybe it could also be a different method name, as this would be more a use case for logging/displaying a string similar to joinToString, rather than “working on a string” by using substring for maybe some logical operation on the string. It could be something like

abbreviate

or maybe

cut