This works for me

fun testKek() {
    class A {
        val x = HashMap<String, Int>()
        operator fun get(s: String) = x[s]!!

        init {
            x["topkek"] = 42
        }
    }

    println("${A()["topkek"]}")
}

yes, it seems straigthforward

@aimozg the explicit return type made it work

thanks, but why does it fail then without?

Map.get

in Java is Object->Object, and K->V in Kotlin

seems like a bug in bytecode generation

shall I open a ticket?

yes

btw, if you want to reply here http://stackoverflow.com/questions/42503938/kotlin-nosuchmethoderror-on-the-get-operator, I will accept it

You can use

uniforms.getValue(s)

on K 1.1.

I want to keep minimalist and concise as possible

instance["x"]

seems nice

Sure. Without

!!

and having to declare return type, it is indeed nice.

Hello everyone Can someone please explain me, why type inference does not work with default values of function arguments? So I have to write

fun disconnect(code: Int = NORMAL_CLOSURE) {}

instead of simply

fun disconnect(code = NORMAL_CLOSURE) {}

I don’t think type inference is intended here. Be explicit 🙂

type of code could be Any too

Method argument defaults are pretty much like variables, their definition is stuck to them so I think it's the same case @miha-x64 Why you advice being explicit?

@bernhard You right, but it's also true about property types

val NORMAL_CLOSURE = 1000

Here

NORMAL_CLOSURE

can also be

Any

(but it is inferred as

Int

)

It’s easy to break some code with type inference. If you change `NORMAL_CLOSURE`‘s type to

BigInteger

, and then to

BigDecimal

, in different versions of library, you will get different (and binary incompatible) signatures and expose some implementation details. In case I described,

fun disconnect(code: Number = NORMAL_CLOSURE)

is preferred.

I am agree with you, but the type of public

NORMAL_CLOSURE

is part of API itself, so changing it is same as changing default argument type to something else

@alilotfi there was a discussion about this a while ago. Can't remember the specific details. But IIRC, its more around the compiler pre-processing and the information it's able to pick up from the class header on first pass (the class type itself and it's method signatures) without any complex analysis.

I guessed that it's the case, but I was not sure. Thank you @kingsley

Why there is no such an overload in stdlib?

fun <T> Sequence<T>.minus(vararg elements: T): Sequence<T> = this.minus<T>(elements)

Hey guys. I have a following class:

class MultiMap<K, V> : HashMap<K, MutableList<V>>() {

    fun put(key: K, value: V) {
        var entries = get(key)

        if (entries == null) {
            entries = mutableListOf<V>()
            put(key, entries)
        }

        entries.add(value)
    }
}

That in Java Spring project fails to compile with:

MultiMap.kt: (5, 7): Inherited platform declarations clash: The following declarations have the same JVM signature (getOrDefault(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;):
    fun getOrDefault(key: K, defaultValue: MutableList<V>): MutableList<V>
    fun getOrDefault(key: Any!, defaultValue: MutableList<V>!): MutableList<V>!

What would a proper fix?

Somehow this class compiles fine when I run via IntelliJ IDEA, but fails with gradle always

😄

how does the type inference solution look like?

that should be legal as you've written it now

no