Is there a way to create a an expected class that could be either a class or an abstract class in different platforms For example,

expect abstract class Thing {

}

actual class Thing {

}

actual abstract class Thing {

}

Obviously the example above doesn't make sense, but it does if you are trying to typealias to already existing code. It is not a huge issue, but just wondered if it existed already

Can you please describe your situation so why do you actually need the

abstract

not everywhere?

Let's say I have a iOS and Android version of a library They provide two simple classes:

Swift:

class SwiftVersionOfSomething {

fun test(): String {

return "hi"

}

}

Android:

abstract class KotlinVersionOfSomething {

func test(): String {

return "hi"

}

}

I need the value of X on both, so in my common module I create. I have no control how they are instantiated and purely just need to access the x value for both It would be useful if I could do something like

expect <Object_With_function> SharedVersionOfSomething {

fun test(): String

}

actual typealias SharedVersionOfSomething = KotlinVersionOfSomething

actual typealias SharedVersionOfSomething = SwiftVersionOfSomething

So basically, we just say we need some object of any type that has a particular function / variable regardless of type (class/abstract class/data class/object)

So what about declaring

interface

?

@kpgalligan talked about empty type-aliases to combat similar issue on Firestore if i remember corectly

If you're trying to map classes between platforms to bridge an api, they tend to be similar but are unlikely to align exactly, so typealiases are difficult. You wind up with a preferred platform and a delegate on the other, generally speaking. To get around that, for the firestore, I implemented methods with expect extension functions rather than defining them on the expect class itself. You might be able to achieve something similar with inline classes, but haven't looked at it too much lately.

great, thanks for all the information, will have a go at what you suggest. I just ended up with a class for each which just is a layer between common code and platform code.