Expect with defaults

[serras]

This is an issue to discuss expect with defaults. The current full text of the proposal can be found here.

This proposal addresses the most common case of lack of reusability in Kotlin Multiplatform projects, by providing a way for expect declarations to define default implementations to be used whenever a platform does not actualize such expect implementation.

TL;DR

• Expect declarations may define a default implementation.
• The default implementation implementation is used when there's no corresponding actual declaration in a platform for an expect.
• Default implementations must define the declaration completely ("all-or-nothing" rule); leaving some parts unspecified is not allowed.

[CLOVIS-AI]

Could we add a syntax to call the default implementation from an actual? I have examples where the actual wraps the default implementation to add pre- or post-processing, but is otherwise identical.

This would be semantically similar to super<Foo>.bar() in classes that implement an interface with a default body.

I don't have any syntax that comes to mind.

[CLOVIS-AI]

Maybe something like this?

actual fun foo() {
    someLoggingOrWhatever()
    expect.foo()  // the default body
}

But expect isn't a keyword right now, so users could have variables named expect.

[serras]

We could, but this goes against the idea of “all or nothing”. In the same way that we don’t propose partial actualization, this proposal tries to cover the 80% case by providing the simplest syntax.

just to reiterate: this proposal tries to be very minimal, and conciously drops some use cases. At least in my preliminary investigation, the use case you mention was definitely not into the core people experience.

[rnett]

I agree that this would be nice, but I also agree it's not required, and it can be worked around easily enough by having a common internal thing they both reference.

[pdvrieze]

Maybe part of this, maybe not, but I find that there is an issue in that expect/actual currently does not support default implementations for interface methods at all. This issue is a significant limitation that goes beyond having to define defaults.

In terms of just defaults for actuals, this also opens the option of incremental defaults, for example a default for all native implementations that is then overridden by an iOs implementation.

[ApoloApps]

This is more on an IDE side of things, but it would be nice for the defaults in expect declarations to be slightly transparent. Kinda like Inlay hints in functions with default values

expect fun hello() = println(“Hello from Common, team!!”)

[1981javadelahi]

Instead of explicitly writing it or using a lambda, we could treat one side as a default or common case. This would allow us to eliminate a frequently used default across all functions—adding it only when the other option is used—thereby creating a more optimized library.
I hope I’ve made myself clear.
This is for those who are more expert than I am.

[lppedd]

This seems a fairly straightforward change (in terms of source changes), and a significant DevEx improvement.

Defining common source sets like nonJvm for defaults deviates from the standard hierarchy and creates unnecessary confusion. The best deal here is defining defaults in the usual commonMain or webMain source set, for example.