When doing `somevar.flatMap { ... }` I get 'not en...

# random

[Ryan Rolnicki]

When doing somevar.flatMap { ... } I get 'not enough information to infer type variable R', which is fine. I do know what R is supposed to be, which means something in my subsequent code isn't what I expect (I think it's clear that R is a Double, the compiler doesn't so there must be something wrong with my code). What I'd like to do to debug is have somevar.flatMap<?, ?, Double>, so telling the compiler 'infer the first 2 types, and I'll provide the 3rd' because computing the K and V generic types is actually somewhat bothersome, as it's part of a slightly more complicated expression.

Is there some way to do this in Kotlin? If not, is there some context action through intellij? If still not, is there an extension?

[jimn]

the minimum example is unclear but have you tried writing the wrapper you describe as inline fun <reified A,reified B > ffmap (A,B,...) ?

[Ryan Rolnicki]

I can, but obviously I don't want to write wrappers for every generic operation - was hoping the tooling or a language feature I didn't know about could solve the issue. Creating the wrapper as needed is fine, and perhaps slightly less onerous than manually computing the K and V types. Seems like this would be a good context feature though, like in this case a context action would be 'Specify type of R', and it creates the correct generic signature from the computed values, and sets the cursor on the remaining value it couldn't compute

[Ryan Rolnicki]

Since it seems useful, I was hoping it was already done

[jimn]

this is a relic of the jvm that just blatantly ignores whatever type/c++ template aspirations you thought you were declaring.

[jimn]

type A is Object. type B is Object.

[russhwolf]

This will help (targeted for 1.7) https://youtrack.jetbrains.com/issue/KT-13394

[Ryan Rolnicki]

Thanks @russhwolf; that's actually a slightly different request. But per the latest comment, it seems like maybe this is actually already implemented as somevar.flatMap<_, _, Double>, which is apparently going to be in 1.7, so I guess that's the answer to my original question 🙂