I really thought that this would work ```interface...

# general-advice

[Stylianos Gakis]

I really thought that this would work

interface A
interface B
class Foo : A, B

fun <T> foo(): T
  where T : A,
        T : B {
  return Foo()
}

But on Foo() I get:

Type mismatch.
  Required: T
  Found: Foo

Would it just be safe here to do return Foo() as T?

p.s: In my real impl the function body has many branches of course, and all of them match the T description of inheriting from both interfaces

[ephemient]

no, if it were allowed you could have

class Bar : A, B
val bar = foo() // foo<Bar>()

[Stylianos Gakis]

Is my best bet making a third interface inheriting from A, B and return that without any generics then?

[ephemient]

maybe. I can't tell what it is that you want though

[Stylianos Gakis]

My real scenario is that I got a marker interface for all of my navigation destinations, which is just interface Destination
Then in some feature, I got a sealed hierarchy of some destinations that look like this

sealed interface FeatureFooDestination {
  data object ScreenOne : FeatureFooDestination, Destination
  data class ScreenTwo(val x: Int) : FeatureFooDestination, Destination
}

And I can not mark the FeatureFooDestination as Destination itself since the you can accidentally try to navigate to that which is just not a thing that is possible (using androidx.navigation with the new type-safe capabilities).

Then I got a function which is returning one possible FeatureFooDestination, so fun getFeatureFooDestination(): FeatureFooDestination and I want to pass the result of that to the fun <T : Destination> NavBackStackEntry.navigate(destination: T) so there's the problem, since I can't pass the FeatureFooDestination returned to the navigate function, since the interface itself is not a Destination even though I know that all of the subclasses are that.

What I've done for now is just have the fun getFeatureFooDestination() return Destination instead since I am only interested in passing that to the navigate function afterwards. This does technically does open the room for error where I return another type of Destination from that function, but since all of this is internal to that module I should be fine I think.