With interface support in `1.6.20` , in the genera...

# javascript

[shaktiman_droid]

With interface support in 1.6.20 , in the generated typescript file, I noticed the addition of __DoNotUserIt of type __doNotImplementIt

Does anyone know reason behind it? It creates an issue if we have to implement that interface on TypeScript app side.

Kotlin Code

@JsExport
interface GreetingInterface {
    val platform: String
    fun greeting(): String
}

Generated .d.ts file

declare const __doNotImplementIt: unique symbol
type __doNotImplementIt = typeof __doNotImplementIt

export namespace <PACKAGE> {
    interface GreetingInterface {
        readonly platform: string;
        greeting(): string;
        readonly __doNotUseIt: __doNotImplementIt; <----- What and why is this here?
    }
}

TypeScript App Usage (example.ts)

class Greeting implements GreetingInterface {
  platform: string = "TypeScript"
  greeting(): string {
    return "this is greeting from " + this.platform;
  }
  __doNotUseIt: typeof sdk.__doNotImplementIt; <----- What to do here apart from adding `!` so compiler doesn't complain
}

[bashor]

The reason is that it’s unsafe implementing Kotlin interfaces outside of Kotlin

[bashor]

if you want to have “external” implementations it’s better to mark such interfaces by external modifier

[shaktiman_droid]

@bashor ok thanks for the response. Will make a note of it 👍🏽

[ankushg]

Are there plans for a way to declare `external interface`s in common code?

[bashor]

@ankushg please file en issue and provide more information about your case

[bashor]

We had an idea to use annotation for common code.

[Mendess]

@bashor why is it unsafe? Is there a document/post explaining the reasons?

[bashor]

There is no concept of interfaces in JS (closed one is mixins), also, we need to be able making instance checks and storing some metainformation e.g. for reflection. So, we generate some additional code for interfaces.

[bashor]

Considering all that just implementing all members is not enough, you need to know and have access to some internals (impl details).

[bashor]

Same for default implementations in interfaces

[bashor]

We have some ideas how we can evolve in the future but no ETA for implementation