I ve a fundamental question about `expect actual` Is Kotlin

Question

I ve a fundamental question about `expect actual` Is Kotlin code in `commonMain` supposed to be able to access code in `iosMain` or `androidMain` even without using the `expect actual` mechanism So if I have different implementations of `fun getPlatformName String` each in `iosMain` and `androidMain` but I don t declare `expect fun getPlatformName String` in `commonMain` am I still supposed to be able to call this function from `commonMain`

Robert Jaros · Answer

`common` code can only access other `common` code

Robert Jaros · Answer

if you create `expect` function or class in `common` you can access it even though the `actual` code will be defined elsewhere

Robert Jaros · Answer

your common code will be eventually integrated into a platform code ios android jvm but you can t access any platform code directly from `common`

curioustechizen · Answer

Okay so the only way for `common` code to access anything else is if it is declared in common using the `expect` keyword

curioustechizen · Answer

Okay understood Thanks

russhwolf · Answer

You don t have to use `expect` though it s usually the quickest way to inject platform code into common You can also define interfaces or lambda parameters in your common code and have your platform code implement them

curioustechizen · Answer

< russhwolf> This was why I asked this question in the first place slightly smiling face It looks like `expect` is not strictly needed I kept coming up with situations where the interface approach does not work and my team mate kept proving that I m wrong So basically anything you can achieve with `expect` you can also achieve with interfaces Of course it is true that one might be more convenient than the other depending on the situation

curioustechizen · Answer

The kotlin docs have this statement gt Also it requires common declarations to be expressed as interfaces which doesn t cover all possible cases I m wondering what are the possible cases that are not covered by interfaces

russhwolf · Answer

For example interfaces can t define constructors

russhwolf · Answer

But depending on how you structure your code they usually don t need to

russhwolf · Answer

I think I have a similar mindset to your teammate in that I tend to have only small amounts of `expect` in my code One of the limitations of `expect` that I ve run into is that you can t swap in other implementations very easily eg for testing So I almost never do `expect class` and tend to limit it to top level functions and values when I do use it

kpgalligan · Answer

I don t think there will be much expect actual in app code as the library ecosystem matures Because expect actual is a new thing the getting started docs tend to talk about it right away and people tend to use it a lot when they start We did the same thing Had a ton of expect actual for the first few months then wound up pulling most of it out in the following months

kpgalligan · Answer

Where expect actual can be useful is in wrapping sdks that have some deeper object graphs We wrapped Firestore which has a lot of nested layered calls and data object replies Doing that with interfaces would mean a lot of wrapping and delegate management <https vimeo com 371460823>

kpgalligan · Answer

Basically they re useful but you should fight the urge to use them a lot and I think getting started docs should push expect actual lower in the priority of things to learn