is there a way to turn a type parameter with upper bound `Any?` into its non-nullable variant? I wou...

# announcements

[robstoll]

is there a way to turn a type parameter with upper bound Any? into its non-nullable variant?
I would like to avoid something like: fun <T: Any> foo(t: T?)

[streetsofboston]

fun <T : Any> foo(t: T?) would do that, wouldn’t it?

[robstoll]

that's the solution I don't want (ah my mistake forgot to add Any as upper bound

[pavel]

I am not sure I understand what you are trying to do

[streetsofboston]

Then I’m not sure what you want.
fun <T> foo(t: T) would be the one you want…

[pavel]

you can do fun <T:Any?> foo(t:T)

[streetsofboston]

But : Any? is the default if you omit it

[robstoll]

fun <T> foo(t: T){
if(t != null) bar(t) //compile error
}
fun <T: Any> bar(t: T){}

[robstoll]

for instance

[streetsofboston]

I see, it’s the other way around 🙂

[streetsofboston]

fun <T> foo(t: T){
 if(t != null) bar<Any>(t) // no compile error
}

fun <T: Any> bar(t: T){}

[pavel]

fun <T : Any> foo(t: T?) {
    if (t != null)
        bar(t) //no compile error
}

fun <T : Any> bar(t: T) {}

works as well

[streetsofboston]

@pavel But then bar can no longer accept null-values….
I assumed that the signature of the functions can’t change, only their implementation

[pavel]

fun <T: Any> bar(t: T){} it never could

[streetsofboston]

Ooops… I meant ‘foo’…. and still that one can accept null values 🙂
Still, the signature of the function(s) change…

[pavel]

yeah, if that change is prohibited then my solution doesn’t work

[robstoll]

ok, take it to a next level, bar<Any> doesn't help in my case because guess what, bar takes a second parameter:
fun <T: Any> bar(t: T, a: A<T>){}

[streetsofboston]

Then if the signatures can change, Pavel has the right solution.

[pavel]

fun <T : Any> foo(t: T?) {
    if (t != null)
        bar(t, emptyList()) //no compile error
}

fun <T : Any> bar(t: T, f: List<T>) {}

[robstoll]

haha... you come up with nice examples, this does of course not work if List would not be covariant

[robstoll]

A might not be covariant

[robstoll]

but I see, in some situations the fallback to Any makes sense 🙂

[robstoll]

oh... and you used fun <T : Any> foo(t: T?) which I want to stay away from if possible

[streetsofboston]

interface A<T>

fun <T : Any> foo(t: T?) {
    if (t != null)
        bar(t, object: A<T>{}) //no compile error
}

fun <T : Any> bar(t: T, f: A<out T>) {}

And changing out to in or nothing still works fine.

[streetsofboston]

Why don’t you want to use fun <T : Any> foo(t: T?)?

[robstoll]

you have to define every single api using it like this then

[robstoll]

it pollutes your api

[streetsofboston]

I see… If it were fun <T : Any> foo(t: T?) : T then this is a nice way of providing the generic, but since foo doesn’t return a T type, you api gets a bit polluted.

[robstoll]

say you have another function baz which wants to use foo, now it has to use the workaround with T: Any and T? as well... but I guess I have to go this way until the new type inference is in place

[robstoll]

I think I saw in a talk that this will be solved then

[pavel]

or you could just stop accepting null params 😉

[robstoll]

yeah.. unfortunately I have to

[robstoll]

btw. thanks for your time 🙂

[ilya.gorbunov]

@robstoll New inference will provide the way to do it, but the current one doesn't have any.