What are pros/cons of using actual/expect instead of interfaces and implementations? I think that interfaces/impls have the following advantages over actual/expect 1. It is more flexible. You can have multiple impls for the same interface, they are easily interchangeable, as opposed to actual expect 2. Interfaces and impls is a concept everyone already understands. Expect and actual provide a different syntax without much added value IMO I'm curious what people's thought about the two are. Let's discuss.

It’s likely you’d use both at once: for example, having an interface and an

expect

factory function defined in common, and then an implementation of the interface and an

actual

for the factory function defined in each platform.

`expect`/`actual` is more like a platform

#ifdef

in C or C++ (or compiling different source files for each platform that implement functions defined in a common header file). You could

expect

an interface in common code, but then have the

actual

interface be a Java Standard Library interface on JVM and something else on a native platform where that interface doesn't exist. You can't accomplish that with traditional interfaces and implementations. There are situations where you could use the two approaches interchangeably, but that's not always the case.

@araqnid why would you need an expect factory function? Cant the impl of the interface just construct it itself?

actual/expect works not only for classes, but also for top level functions and companion objects, which you cannot achieve with interfaces

@Orhan Tozan but you wouldn’t be able to do that from common code, like you can call Dispatchers.Default, for example.

Expet/actual is nice for the use-cases that interfaces can't handle, but I tend to avoid using it when I can use an interface. For example I don't like expect classes with expect properties/functions inside of them, because there's no way to swap out an alternate implementation. In that case I'd rather do an interface and, if needed, an expect/actual factory function to construct it in common.

I’m sure this is covered by the responses, but here’s my basic thought process. First, interfaces and lambda definitions are kind of in the same bucket, and I use them to define functionality that can be provided by the host platform. For purposes of discussion, assume

()->Whatever

is just shorthand for an interface with one function.

I see a point there, expect/actual is unmissable for KMP functional programming

However, bridging native API’s is a whole different use case. I talk about that here. https://vimeo.com/371460823. Doing that with interfaces would be pretty messy.