Given these few lines: ```open class A interface B...
# getting-started
v
Given these few lines:
Copy code
open class A
interface B
class AB: A(), B
class CD: A(), B
fun <T> foo(t: T): Nothing? where T : A, T : B = null
val a = foo(AB())
val b = listOf(AB()).map(::foo)
val c = listOf(AB(), CD()).map(::foo)
The last one with
c
is not compiling. Does anyone have an idea how to make the last line also work? It gives the compilation error
Type parameter bound for T in fun <T : A> foo(t: T): Nothing? where T : B is not satisfied: inferred type Any is not a subtype of A
So it seems while the created list could be of needed types
A
and
B
, the type inference is not smart enough here but creates a
List<Any>
Is there a way to fix this, e. g. to explicitly define the List type somehow? Interestingly the type inference in IntelliJ is smart enough to handle it properly and does not show an error, only the compiler bails out.
k
The new type inference makes the list into a
List<{A & B}>
, something the old one couldn't do. The compiler still uses the old inference for now but that can be changed with a compiler flag
v
Ah, will try that, thanks. Unfortunately I cannot control compiler flags in the end, because this is about using the TeamCity Configuration Kotlin DSL and I fear that they do not use the flag there, but I'll see. In case I cannot use the new inference, is there a manual work-around? I would be fine with specifying the list type manually or something, but afair I tried specifying
List<{A & B}>
and it was not valid syntax.
Any idea @Kroppeb? Especially even with the new inference it does not work. I tried my example on play.kotl.in with 1.4-M2 which should have the new inference enabled by default and it still does not compile.
Ah, no it works on play.kotl.in, it just didn't switch the version properly it seems. And with the compiler flag it also compiles, so the new inference works fine. But the question remains, I cannot influence the compiler flags or version where the code needs to run afaik, so is there a way to properly do it with the old type inference?
k
I don't think so
v
Hm, bad, then it will probably have to be parameter type
A
and throw exception if not
is B
or the other way around until 1.4 is used :-(