Should the second snippet not give a compiler error?

val imap = mapOf("a" to "a")
// val mmap = imap as MutableMap

    imap["b"] = "b" //compiler error

val imap = mapOf("a" to "a")
    val mmap = imap as MutableMap

    imap["b"] = "b" //runtime error java.lang.UnsupportedOperationException

you cannot change immutable map

What's with

mmap

? What is it for?

This also does not give compile error:

val imap = mapOf("a" to "a")
imap as MutableMap // Won't compile if i remove this
imap["b"] = "b" // Compiles just fine, but obviously runtime error

seems like

as

acts more like a statement than an expression 🤔

@arve un contraire,

as

is a pure expression - it returns a value of another type, it does not modify existing one. It is pretty much impossible. It is supposed to work like this:

val imap = mapOf("a" to "a")
val mmap = imap as MutableMap
mmap["b"] = "b" // works

That was what I would have expected as well. But why does my snippet above compile?

not sure what u want to achieve, but u can do this

val mmap: MutableMap = mapOf("a" to "a")
mmap["b"] = "b" // also works

@arve due to smartcast. By statement

imap as MutableMap

(even though it did not have obvious effects) you presumed that

imap

is actually mutable and compiler took it for granted.

All right. My expectation would be that the statement was thrown away 😛

I was actually surprized a little bit too, I didn't know that smartcasts could work that way. A bug, perhaps? 🤔

It certainly feels like a bug if

as

is supposed to be an expression

oh God, I just realized that OP's example implies smartcast misbehavior too

This all looks like it's working as intended. Smart casts have worked like this since I can remember.

This behaviour happening because actually

MutableMap

doesn’t exist on Java side and will be replaced with java’s Map interface (every map is “mutable” on Java side from types point of view) So Kotlin mapOf function returns instance of SingletonMap which is immutable, than you cast it to Map inteface (which is valid cast), so Smartcast now sure that this type is MutableMap, but when you call “SingletonMap.put” UnsupportedOperationException will be thrown on runtime

I don’t want to achieve anything with the code I am just wondering why I don’t get a compiler error in the second example since it should behave as in the first example.

This ticket https://youtrack.jetbrains.com/issue/KT-15138 And ones it references explain the issue pretty well, also @gildor mentions

SingletonMap

. That's the issue as well

@egor But should not only mmap be treated as a MutableMap?

@samir yes it should. But smartcast doesn't think so

So is this a bug(improvment on smartcast) or expected behaviour?

it’s expected behavior

Ok, thanks(all) for the clarification

Any Kotlin Map can be casted to MutableMap without runtime exception, because on runtime only java.util.Map exists

It actually doesn't seem like a proper behavior, the one that you want to expect, does it?

Why?

This discussion already took place in Telegram Kotlin chat and honestly I don't know what is it to be done apart from changing

mapOf

behavior (though, this is actually impossible now) for it not to return

SingletonMap

. You also can't throw

ClassCastException

, because casts are not broken. There is required a total reimagining either of the whole collections-related things or of the type system. Or it's just to accept that

mapOf/1

,

listOf/1

etc. work that way and from time to time explain it. But imho it's still rather silly that one of the most usable languages has such issue

what is it to be done apart from changing

mapOf

behavior (though, this is actually impossible now) for it not to return

SingletonMap

I don’t understand how this somehow help? You still have any other implementations of Map, not only in Kotlin, any method can return you kotlin.Map and it can be any type

The main issue is that you can accidentally cast result of

mapOf

to

MutableMap

, which will result in notorious behavior. Yes, there's a bigger problem of Java interop, but you usually don't encounter it because you work with types you are aware of.

Would probably prefer if smartcast don’t assume on

imap

-> compiler error.

also why anyone would cast type to MutableMap?

Don't ask me, I never use mutable collections :^D But such questions and issues come up, right? Meaning some people, at least initially, suffer from it

Smartcast is not related to this issue. Imagine if you cast some unknown list to MutableMap (which is already not safe, runtime operation) and just return it from a function, no smartcast involved, but it would be the same behavior

I think it is odd that it changes the behaviour of the original variable. Makes sense if

mmap

execute put but not when

imap

does it

Why do you think that I think that

ClassCastException

is better? I explicitly said that it is nowhere to be thrown, nor there is the reason for it

imap as MutableMap

statement changes compiler behavior on

imap

feels error prone.

I see what you mean. But this is power of smartcast

How you can accidentally cast something

And still you get runtime exception from something that you expect not to fail

Casting also throws runtime exception

Because casts are fine, according to JB's explanation: there is only

Map

existing in runtime, you can't (probably can't) fix it by adding or changing interfaces

And if Kotlin would have own collections, such operation would always throw ClassCastException

As I said, I would like to see this problem solved, because it is behavior inconsistency of JS level, but I don't know how. At the very least, casts could work better 🤔

Of course I agree that this is not perfect behavior, but you can do nothing in this case. This is price that you pay to have great Java interop and performance no need to have own collections, no need to cover them from/to java ones

No, I meant figuratively

Anyone who rely on implementation detail of any API already in trouble

That only JS could have more unpredictable behavior

This is how use sun.misc.Unsafe

I don't think it is. Success of collection editing relies on how many arguments you passed to

mapOf

, like, what? Again, apart from the fact that it's not really smart to cast maps to mutable maps. There are circumstances and there are people with Java background, who haven't yet got used to immutable collections

What is "success of collection editing"?

uhhh, it's kinda weird I can't rephrase that

People with Java background should understand that they shouldn't just use any random collection instance returned from external API as mutable

"success of collection editing" is a successful (that is, without exceptions or problems) mutation of a collection