I’d argue that in most cases, the cases for which a hash table exists in the first place, not finding a key is perfectly normal and expected.

Fair enough

There's also the argument that if you know all the keys before hand, you should probably just use an object weigh properties. I can see the argument for both sides.

(Though we're probably getting a bit #random here)

Moving there

By the way, we have a plan to introduce

getValue(key: K): V

extension for maps, which would throw when the key is not there (unless the map provides a default value somehow)

@ilya.gorbunov Should rename it to

getValueAndPleaseBeThere()

🙂

or

getValueFingersCrossed

I'm not saying that Kotlin should support this and that, but I don't think the reason it shouldn't be supported is because some editors (or IDEs) write the code for you anyway.

that's a strong simplification of my argument

But isn't that what you're saying? That since you're not writing the imports yourself (IDEA does it for you) it doesn't really matter if the language will support that specific way of doing imports or not?

I'm not trying to be rude, btw. Hopefully when you read my text it's not with a snarky tone of voice. Just making discussion. 😛

I'm saying that not all IDE-generated code is equal

you could say because you have to type a lot of curly braces, Kotlin should get rid of them as well

do you see where this line of argumentation is going?

Of course, and some languages do that. Again, I'm not saying that Kotlin should support this and that feature (that syntax for importing being an example), but the argument shouldn't be because IDEA manages that for you, it should instead be that it makes the code less readable or harder to reason about, for instance.

if I have a conflict with the

set

function (from operator), do I have any chance to rename the operator one?

In the case of curly braces that you mention, I would argue that without the curly braces it's harder to read and understand the code (where blocks of code begins and ends).

I think I have been misunderstood. When I said I have mixed feelings I meant this: On the one hand I think the argument that editors will fix all your imports for you doesn't justify writing them out fully On the other hand I think imports should all be written out fully - merely because it makes the code clearer.

is there a way to make Kotlin emit Java 8 compatible parameter reflection data?

i'm guessing the answer is "no" until Kotlin starts emitting Java 8 bytecode in general

ah, seems like that feature is in Kotlin 1.1, albeit off by default

quick question, but is there a way to have an equivalent of 'new T()' from c# in kotlin? i'm referring to generic constraints

On the other hand I think imports should all be written out fully - merely because it makes the code clearer.

Perfect, that's exactly what I wanted to hear. simple smile

@jan.rabe Ah… sort of. There’s the reified keyword but it probably only solves some of the use cases you are looking at. That said, there may a better solution (like passing a factory lambda). https://kotlinlang.org/docs/reference/inline-functions.html#reified-type-parameters

thanks

There's no way to impose a no-arg c'tor constraint on type variables unfortunately

It has been requested. There is a bug filed in YouTrack for it.

there is a lot of code you avoid writing due to this feature, it was impossible in java without doing the infamous and unreliable reflection action afaik, hence the curiosity

Why isnt

() -> T

good enough ?