with hmpp can i define an expect class in commonMain, redefine it as an expect in intermediateMain with more functions, and then actual it in platformMain?

I’ve never tried, but you might be able to hack it with a typealias commonMain

expect class Foo { ... }

intermediateMain

actual typealias Foo = Bar
expect class Bar { ... }

platformMain

actual class Bar { ... }

ahaha oh my god this is horrible

@jw This is what we call ‘expect refinement’ and the compiler is not able to do this. The commonizer is special and has a way to refine APIs down the line. This is the first time I see users publicly asking for such a feature for library authors!

Oh wow I've had this need for quite some time. I just thought HMPP may have enabled it.

No and tbh, there is not even a ticket for this afaik 😕 This indeed was one of the big blocker for commonizing beyond the first level of “common” source sets. Supporting something like it would not be a lot of effort. We never rejected the idea, but given the efforts for HMPP and the current state of that we think it’s not on the top of the queue 😕

If you're ok with another layer of workaround, you could try an opt-in annotation to keep

Bar

out of public API.

@RequiresOptIn
annotation class InternalApi

@OptIn(InternalApi::class)
actual typealias Foo = Bar

@InternalApi
expect class Bar

But it might not be viable for you because then the new members of

Bar

are also not public API.

That annotation can also be made internal to fully prevent opt-in outside the module.

Yeah I need them to be public API, unfortunately. I have some workarounds in place by using interfaces which are themselves expect/actual to mix-in the new API but that also creates new public types. At least they're supertypes, though, and not subtypes, so you remain mostly blissfully ignorant of their presence.

Oh yeah that's a good trick too