Is there any way to get the typealias target type when overriding a method on a specific platform:

// Common
expect class Input

interface Foo {
  fun doStuff(input: Input)
}

// JVM
actual typealias Input = InputStream

// Use site
object : Foo {
  // I want this type to be `InputStream` when implementing this
  override fun doStuff(input: Input) {
    ...
  }
}

Common can't see platform-specific code, so if object : Foo is in Common, it can't see jvm's InputStream. If Foo is in JVM, then you can safely do this: `` override fun doStuff(input: Input) { input as InputStream } ``` The reason being that your JVM backend is what supplied actual Input, and you know it supplied InputStream as that type. (the typealias has nothing to do with it)

I should have mentioned that “Use site” is not in the common codebase but rather in the consumer project which is likely platform specific. Also, you wouldn’t have to cast it since

input

is already a

InputStream

. You can actually just change the argument type to be

InputStream

. Most of my `expect`s are

internal

to not pollute the global namespace but then the default implementation is red since

Input

is not accessible

I assumed you couldn't change the argument type because possibly common code is what passes the argument.

It’s more of an IDE question I suppose. Ideally I would never want to leak my

expect

types to the consumer if it’s a

typealias

I guess I don't really understand what you mean by "leak your expect types". The types for expect should be your common interface. For input streams, buffers, things like that where you have multiple platforms, the way I typically approach it is to define a common interface in common, then take the native backend implementations, such as InputStream, Buffer, etc and write a wrapper that uses the native implementation in the 'common' way. However, sometimes that's too much work and it's easier to do closer to what you're doing and just make up a type that always gets coerced at the platform's use site. Either way though the expect type should be however it's used in common code.

So for example regarding

Input = InputStream.

I don’t want consumers of the library to have to feel like it’s a separate type when it’s actually just an

InputStream

. Ideally the fact that it’s called

Input

in the common code should be an implementation detail and should not concern the consumers

well, it has to be a separate type when it's common code or anything you're trying to expose to common

Of course, but I just wish there was a way to keep that definition from being visible to the consumer which would only see the typealias target

oh I think I get what you're saying now

When implementing the interface on the Jvm it would be great if

Input

didn’t exist for them. I hoped making it

internal

would do just that and I suppose it did to some extent. But instead you get compile errors unless you manually change

Input

to

InputStream

yeah, I could imagine a way if common code never got compiled as its own thing, but common does get created as its own library

I’d be find with a

@JvmName

or something like that. I don’t need to specify the full path name but rather just a typealias