A modern programming language that makes developers happier.

kotlinlang

I expected that a Map is a Map, and the `in` operator would be consistently interpreted as `containsKey(..)`.  The fact that it does not cost me over an hour of debugging, and I think is a surprising result for users.  I would expect to be able to switch a collection between `HashMap`, `ConcurrentHashMap`, ... _any_ `Map` and have the code behave consistently.

brett.wooldridge: I think its neither of both. The `in` operator is mapped to `contains()` in kotlin. So the problem with ConcurrentHashMap is, that it defines its own legacy `contains()` which calls `containsValue()`. There is not really a way to override the behaviour of `ConcurrentHashMap.contains()` outside of the class itself

Please report this in <http://kotl.in/issue|kotl.in/issue>. It at least deserves an inspection warning in IDE. Maybe there is something that can be done in the language for this special case, but I wouldn't expect this.

As a side note: tests help. :slightly_smiling_face:

But if the stdlib can do an instanceof equivalent, that would be great.

KT-18053 Unexpected behavior with "in" infix operator and ConcurrentHashMap.

By the way, I love the bejesus out of Kotlin.  Been using it for ~8 months and I look forward to opening the IDE everyday.

Doing server-side greenfield development.

You may want to send it directly to <#C09222272|> instead of in thread so more people see it. JB devs like to see happy users :slightly_smiling_face:

Hard to resist the temptation to go back and rewrite something that is already working every time I learn something new. :slightly_smiling_face:

BTW, I'm the guy who is implementing daemon-resident Kotlin compilation support in Buck Build.  4 months in the making, but it should drop today or tomorrow!  <https://github.com/facebook/buck/pull/1283>

If you guys aren't using Buck, I highly recommend it.  Incremental CLI compilation times of like 0.1 seconds, prompt-to-prompt with single digit number of files changed.