Personally, I turned it off. Too verbose and I prefer to rely on the developer to explicitly use parameter names when there is some potential ambiguity

I'd like it to be possible to turn it off for single argument functions.

list.drop(n: 5)

doesn't look useful.

I think "single character parameter names" would be a better heuristic

I browsed through my code and don't see too many of these wie-heist-er tooltips. Most notably I would not want to see them on my extensions like:

fun <T> List<T>.minusIndex(index: Int) = subList(0, index) + subList(index + 1, size)
fun <T> List<T>.splitAt(index: Int) = Pair(subList(0, index), subList(index, size))

but I'd rather not change

index

to

i

or something...

But I also have a few functions taking

Boolean

, where it helps (but I should really refactor those functions into two, where one calls another).

@User uploaded a file: and commented: @yole what's the motivation behind showing hints for expressions with eliv operator?

I'm not sure this is actually necessary; we'll see

assertThat(somethingSomething).isEqualTo(expected: ...)

is annoying 🙂

@User uploaded a file:

@User uploaded a file:

With 1.1.3-dev-1810.

Apart from that, everything compiles correctly and my unit tests pass, but the clean build takes 3 times longer.

@jonasb has left the channel

@yan is it known that incremental kapt3 has issues after a build failed?

@kirillrakhman Not yet

ok, I'll try to reproduce and file an issue

📣 📣 📣 We're happy to announce the EAP for Kotlin 1.1.3. The final release is going to happen in the first half of June. What's new - Rainbow highlighting for local variables and parameters - Inline hints for parameter names (enabled by default) and inferred types (disabled by default, can be enabled in Settings | Editor | General | Appearance | Show parameter name hints | Configure...) - Performance and memory usage improvements in the compiler and IDE plugin - Improvements in the performance of generated bytecode - Lots of bugs are fixed in the compiler and IDE More details are available here: https://discuss.kotlinlang.org/t/kotlin-1-1-3-eap/2631/2

Inline hints for inferred types sounds awesome, can't wait to try it!

View > Expression Type seems to be hit or miss for me, especially when lambdas are involved

please file issues for cases when it doesn't work

OK, will do

is 1.1.3 compatible with AS 3.0?

no

because 3.0 isn't out yet? 🧌

i knew the answer and it still made me laugh

AS 3.0 includes a special handcrafted artisanal build of the Kotlin plugin binaries, and we couldn't build 1.1.3 in the same way 🙂

the next 1.1.3 update will be compatible with 3.0 canary 1, though

is the bundled version 1.1.2?

yes