so me and a cofounder just spent 10 minutes runnin...

# language-proposals

[groostav]

so me and a cofounder just spent 10 minutes running down an exception that boils down to a "key not in map exception". One reason is because a junior dev was suppressing the exception, but another reason is because when business rules dictate that a map will contain your key, we simply write map[key]!!. I suppose this is our mistake and we should instead write map[key] ?: keyNotFound(map, key) but that's clunkey. Could write an extension function but that means we loose the slick square-brackets syntax, and its though to make idioms without them being part of the standard-lib.

[ilya.gorbunov]

groostav: Map.getValue(key) is a part of stdlib

[groostav]

so i guess what I'm asking for is some aliasing to allow me to route map[key] to map.getValue(key)

[groostav]

To bring this up again (because its annoyed me again), would the std-lib consider adding an

/** doc that says its not like javas dictionary but C#s dicitonary*/
interface Dictionary<K, V> {
  operator fun get(key: Key): V //nonnullable V
  //...
}

fun <K, V> Map<K, V>.asDictionary() = doFacading()

?

[poohbar]

Kotlin's map works this way to keep it consistent with Java's map ..

[groostav]

right, and im not saying thats a bad thing, but I was wondering if we could create an interface Dictionary and a method asDictionary() to give you back something that works with nonnull return values

[ilya.gorbunov]

@groostav file this proposal to YT please, so it won't get lost in slack.