is there a way to turn a type parameter with upper bound `An

Question

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 lt T Any gt foo t T `

streetsofboston · Answer

`fun lt T Any gt foo t T ` would do that wouldn t it

robstoll · Answer

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

pavel · Answer

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

streetsofboston · Answer

Then I m not sure what you want `fun lt T gt foo t T ` would be the one you want

pavel · Answer

you can do `fun lt T Any gt foo t T `

streetsofboston · Answer

But ` Any ` is the default if you omit it

robstoll · Answer

fun lt T gt foo t T if t = null bar t compile error fun lt T Any gt bar t T

robstoll · Answer

for instance

streetsofboston · Answer

I see it s the other way around slightly smiling face

streetsofboston · Answer

``` fun lt T gt foo t T if t = null bar lt Any gt t no compile error fun lt T Any gt bar t T ```

pavel · Answer

```fun lt T Any gt foo t T if t = null bar t no compile error fun lt T Any gt bar t T ``` works as well

streetsofboston · Answer

< 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 · Answer

`fun lt T Any gt bar t T ` it never could

streetsofboston · Answer

Ooops I meant foo and still that one can accept null values slightly smiling face Still the signature of the function s change

pavel · Answer

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

robstoll · Answer

ok take it to a next level `bar lt Any gt ` doesn t help in my case because guess what bar takes a second parameter `fun lt T Any gt bar t T a A lt T gt `

streetsofboston · Answer

Then if the signatures can change Pavel has the right solution

pavel · Answer

```fun lt T Any gt foo t T if t = null bar t emptyList no compile error fun lt T Any gt bar t T f List lt T gt ```

robstoll · Answer

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

robstoll · Answer

`A` might not be covariant

robstoll · Answer

but I see in some situations the fallback to `Any` makes sense slightly smiling face

robstoll · Answer

oh and you used `fun lt T Any gt foo t T ` which I want to stay away from if possible

streetsofboston · Answer

``` interface A lt T gt fun lt T Any gt foo t T if t = null bar t object A lt T gt no compile error fun lt T Any gt bar t T f A lt out T gt ``` And changing `out` to `in` or nothing still works fine

streetsofboston · Answer

Why don t you want to use `fun lt T Any gt foo t T `

robstoll · Answer

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

robstoll · Answer

it pollutes your api

streetsofboston · Answer

I see If it were `fun lt T Any gt 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 · Answer

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 · Answer

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

pavel · Answer

or you could just stop accepting `null` params wink

robstoll · Answer

yeah unfortunately I have to

robstoll · Answer

btw thanks for your time slightly smiling face

ilya.gorbunov · Answer

< robstoll> New inference will provide the way to do it but the current one doesn t have any