^^ I’d like to do this without needing a

var

Would love to get feedback on this proposal here: https://github.com/Kotlin/KEEP/issues/184

What do you think about adding a

repeat

top-level function which doesn’t take the argument for the number of times that it should execute the block, essentially sugar for an infinite loop?

inline fun repeat(action: (Int) -> Unit) {
    contract { callsInPlace(action) }

    var index = 0
    while (true) {
        action(index)
        index++
    }
}

I’m finding that this “repeat indefinitely” pattern is starting to occur more frequently with coroutines, and it could be nice to have a nicer syntax for it.

Random(5)

works fine, but I want a seed generated by the platform.

Is there nothing better than

Random(Random.Default.nextLong())

?

U

can be

String?

for example.

Manually, probably

:(

You can use reflection, or convert it to JSON using one of the many libraries and parse it back to a map.

Its fine - i just wrote an extension function so i could do it everywhere nicely

There doesn't seem to be an easy way to expand/reduce or shift an

IntRange

on one or both sides. Am I missing something?

I wonder how common that operation is. Didn't have any use case yet, maybe that's why it's not in stdlib? What's yours?

dealing with a table whose column widths and border widths are defined in parallel arrays. i want to sum the width of a cell which spans multiple columns. this means X until X + colSpan column widths and X + 1 until X + colSpan - 1 border widths. I want to inset the IntRange I already have for columnSpanIndicies so that I can use it on the border widths without referencing the original input values or manually doing math on both ends (which are both error-prone and do not represent the relationship of column width indices to border widths).

I think Nicolas' point is that the return value needs to account for the possibility of no result from the reduce, as sequences can have 0 to many elements.

Nullable return would definitely be better than it blowing up with a

java.lang.UnsupportedOperationException

Is there any issues for Base64 and the StdLib String?

I can’t make a copy of it before hand :(

Nvm i can

and on that note... IntRange appears to conspicuously lack toIntArray() operator which makes

foo[3..1]

very awkward to cast to the above

i don't know how I would assume different default behavior to multi-index get operator, but if i were new to kotlin and wrote it with the spread operator I would probably bury the potential memory leak deep into compounded technical debt

the more important feature is having multi-index operators seems like an expression-y kind of thing to a greater overall benefit, where the inclusion into stdlib makes kotlin slightly more friendly while also closing a vector of vararg usage that I have personally experienced as a memory leak ... god knows how many years after varargs have been in the jvm

has anyone written a SoftReference Lazy perchance?

apparently its integral to groovy Lazy @Lazy(soft=true) will use a soft reference instead of the field and use the above rules each time re-initialization is required.

Would you like this to be a thing?

Iterable<Pair<K, V>>.toSortedMap()

@ Anyone? I have a cursor for directbytebuffers. this cursor randomly seeks to mmap backingstore offsets and performs a functor over n fields to map them positionally into the graph of idempotent program state. there are composable Unary operators applied to these idempotent rows. the abstraction i chose first was Array<Array<Any?>> naively to see how it worked out, which works up to a certain number of rows and then kills the jvm heap in order to support a future definition of easily parralellizable streaming i went with Array<Flow<Any?>> so that in thoery my idempotent state is only as expensive as decoder access in time/memory. this works up to a certain number of rows and then kills the jvm heap. but that number is a bit lower than i predicted. this also introduced a boundary of suspend on functions i didn't previously have making certain operators less extendable. i have produced a little taxonomy of vectorlike types and operations. i call it keyboard practice in jest, and while it may overlap the stdlib it seems like this file addresses the containment of spread operator copies when using varargs, and not using varargs makes excessive keyboard practice. i digress -- this is a list of candidate idemoptent mementos of iterator state for mmap backed directbytebuffers. https://github.com/jnorthrup/columnar/blob/a90f816460fa2390a527d65f0238310aee168034/src/main/kotlin/columnar/VectorLike.kt so the question... sorry for such a lengthy prelude, is "does suspend and thereafter Flow induce extra inlining and extra captured state when composing deeply with Unary Operators (Function1<T,T>)" ? among the "Vector-like" type options is there going to be a stack reference retention to parent state that is less duplicated by hot options than by cold options?

It would also be nice to optimize

.map()

,

.filter()

etc. for empty collections in order to spare the useless allocation 🤔

Example

where

getType()

is just

inline fun <reified T> getType(): KType {
  return typeOf<T>()
}