so following the same logic we would also need to support the

int

keyword because it exists in the Java documentation

so once again, a

java.util.Map

coming in from Java code does not get translated into a

kotlin.MutableMap

. instead it becomes a platform type, which is a more complex thing

so we are not saying anywhere that “`java.util.Map` is the same thing as a `kotlin.MutableMap`"

ah, ok. Thank you @yole for the explanation. Gonna re-read the docs on type mapping.

@udalov: @yole : https://youtrack.jetbrains.com/issue/KT-10411

it is not an error for a reason, you could've asked here first )

Hi everyone, Here’s a request for your feedback in our discussion forum: https://discuss.kotlinlang.org/t/public-review-of-the-standard-library-apis/1362 We’d really appreciate your help in polishing the APIs of the Standard library before 1.0 Thanks!

<!here|@here>: we are listening! simple smile

"We will do our best to avoid adding public methods and fields to existing classes" <- why?

the jdk adds such things all the time

measureTimeMillis was made inline, right?

@kirillrakhman: yes

@mikehearn: We are not JDK. If two libraries or plugins bring two different versions of Kotlin runtime into the same classpath, the (random) one that comes first wins, and if there’s a discrepancy between members of classes, some code may fail with NoSuchMethodError

yes, such conflicts are unfortunate, but java devs have to handle them anyway, as no libraries i'm aware of have a "we will not add members to existing classes" policy. the fix, as long as newer version is backwards compatible with old, is just to use maven/gradle to forcibly pin the dependency graph to a single version

or possibly when jigsaw comes along use some kind of container that manages the module layers

it'd be unfortunate if either (1) the stdlib grew in weird ways due to trying to meet this constraint or (2) there was a temptation to do a backwards-incompatible Kotlin2 after only a few years, due to this artificial constraint

There is inconsistency in naming of factory methods for arrays: Array vs array, etc

I have been going to fill a BR. Do it now, or better discuss it here?

@voddan:

Array(Int, (Int) -> T)

and

PrimitiveArray(Int)

are constructor-like functions, thus their names are spelled like a type name. Do you feel it is inconsistent?

Let me check on the latest docs

@mikehearn, @abreslav - Java (well the JVM) has strict rules about binary compatibility. Is it not enough to rely on that, as Java does?

@ilya.gorbunov: I often define functions that look like constructors.

@natpryce: Which rules do you have in mind?

JLS chapter 13

(I had to dig into this to understand why switches on large enums waste so much heap memory)

here's an idea from #C0922A726. How about a kotlin equivalent for

Class.forName

?

And another I had earlier: a Kotlin equivalent for

System.exit

that returns

Nothing

instead of

void

/

Unit

(if there isn't one already)

Please create respective issues in YouTrack, sounds good to me.

exit() shouldn’t probably be top level function, though, could cause confusion otherwise.