MapWithDefault

should be subinterface of

Map

Any reason why

KClass

is not implemented

Serializable

?

serializability was a design error in the JDK. why perpetuate it?

I expected it to be Serializable same as Class, now i need to write custom boilerplate code to serialize/deserialize KClass or converting to Class. Btw what's wrong with Class serialization in Java?

the format's fragile. it's an attack vector, etc.

I see, but it would be same problem if i'll store class info as String for example

tl;dr classes should not be serializable directly, use external mechanisms to dehydrate / rehydrate objects if necessary. IIRC serialization came about because Java wanted to be able to send whole objects to other JVMs, something that's become less and less reasonable since its original proposal.

it was born in the CORBA/RMI days.

@stepango all you need is the class name. then just load via that name.

yeah that is what I'm doing now😊

Serializing classes is akin to sending bytecode around, something that's not exactly easy to do (typically, the class already exists on the receiving end and you classload it)

hm wasn't there something already like that

@jw this is good but not exactly the same 🙂

Adding more and more stuff to #stdlib just because they are generic doesn't help anyone. If you grow a lib too much, you have problems with discovery. I still find new useful functions after nearly 2 years of using K. I have a bunch of extensions for collections so generic, that I would expect them to be, but they were not in #stdlib. You may always create a library and upload it to jcenter/mavenCentral if you feel many can benefit from it. (e.g. https://github.com/evanchooly/manhattan)

For exampe why there is

foldIndexed

,

mapIndexed

and

filterIndexed

, but not

flatMapIndexed

or

filterNotIndexed

in #stdlib?

@mg6maciej Maybe they're not used as often? Anyway, you may call

withIndex()

on an

Iterable

or

Sequence

to get index-value pairs.

That's what I do. Not a big deal for me 🙂

or write your extension functino which does that

probably they're not often used, not a good idea for the stdlib to do edge cases esp when they're simply implementable

Note that the reasoning "you can always write an extension and publish it as a library" has lead to

left-pad

being a separate library in JS ecosystem. 😉

You cannot remove thing that was put in maven central tho.

At least not as easily.

@User uploaded a file: Collections.kt

Do you want these in #stdlib ? I'm sure such functions are created by 1000s of devs, but should they really be in #stdlib ?

shuffled

and

splitAt

is something that we consider useful to have. Haven't considered the others.

Yeah, I saw kotl.in/issue for

shuffled

.

Adding

kotlin.Random

typealias and KN implementation might be useful to many.

But even if

splitAt

was in #stdlib it would use `drop`+`take` equivalent and not

subList

.

found it

pairs
  .filter { it.second != null }
  .filterIsInstance<Pair<String,Double>>()
  .toMap()