@orangy: the Interop section already contains information on the type mapping. what we need is a separate page explaining how collections work

that’s what I meant

btw, @yole, would also be nice to have a separate page on all the type mapping, including nullability, cause it is not kotlin-to-java, nor vice-versa

and I just got a question about java types: how this is not a bug: http://stackoverflow.com/questions/34255329/does-java-util-hashmap-not-implement-java-util-map-in-kotlin ?

I mean, shouldn't

java.Map

be correctly mapped to

kotlin.MutableMap

?

Kotlin sees

java.util.HashMap

as a class implementing

MutableMap

, which is a different interface from

java.util.Map

what do you mean by “including nullability”? mapping nullability from Kotlin to Java and from Java to Kotlin are completely orthogonal issues

1) I would expect

java.Map

to be indistinguishable from

kotlin.MutableMap

2) I wanted to say that now nullability is under "Calling Java code from Kotlin", being a rather large part of it. I think it deserves a separate page, considering its complexity. It would be logical

ping: @yole

can you please explain why

java.Map

is not indistinguishable from

kotlin.MutableMap

?

@udalov can explain this better than me

thanks!

@udalov?

is this your question -- why don't we treat

java.util.Map

in a Kotlin source as a

kotlin.MutableMap

automatically?

I don't know, is there any reason to do so? I see 0 use cases. You should use

kotlin.Map

/

kotlin.MutableMap

in Kotlin sources

well, the result is that java interface

java.util.Map

can not be used like other java interfaces. See the question on SO: http://stackoverflow.com/questions/34255329/does-java-util-hashmap-not-implement-java-util-map-in-kotlin

There's a warning on

java.util.Map

which literally says "This class shouldn't be used in Kotlin. Use kotlin.Map or kotlin.MutableMap instead". Doesn't it help?

Even a quick-fix is available

OK. For me the warning is more than enough; I would never come up with such a problem on my own, believe me

how hard would that be to implement the issue?

after 1.0 , of course

why?

because I can not see a single reason why something is prohibited for one Interface

why give two different names to one thing?

all other classes and interfaces have a unique name

and here you’re suggesting to allow to refer to a thing in Kotlin code with two different names that have exactly the same meaning

well, they are two different things in the documentation if you count Java + Kotlin docs, which you should

And I don't thing there should be no warning on

java.Map

, so one of these things is definitely better than the other