What's the reason for exposing a `__doNotUseOrImplementIt` field in the generated d.ts files? ```exp...

# javascript

[Edoardo Luppi]

What's the reason for exposing a __doNotUseOrImplementIt field in the generated d.ts files?

export declare namespace com.my.pkg {
    interface MyType {
        toString(): string;
        readonly __doNotUseOrImplementIt: {
            readonly "com.my.pkg.MyType": unique symbol;
        };
    }
}

[Artem Kobzar]

2 reasons:
1. To make the interface nominal typed instead of structural
2. To prevent implementing Kotlin interfaces from TS

[Edoardo Luppi]

@Artem Kobzar got it, thanks! So basically it's there to stay.

[Artem Kobzar]

About nominal vs structural.
In TS types comparing by its structure, so, if you have two classes:

class Admin {
    constructor(public readonly email: string) {}
}
class RegularUser {
    constructor(public readonly email: string) {}
}

Their instances are identical for the type checker: https://www.typescriptlang.org/play?ssl=6&ssc=2&pln=1&pc=1#code/MYGwhgzhAECCAmBbAlgO2gbwFDV9YA9qhAC4BO[…]A2IAkQuPaRD47FT88ulAHpf6AAOQA8tAAKJaLTArRAA
The same is for interfaces, but in Kotlin all the interfaces are nominal, so they are not equal even if they have the same structure: https://pl.kotl.in/U1gmb9McA

[Artem Kobzar]

About the second point.
Right now you can't use the regular implements keyword in TS to implement an interface because interfaces in TS are not runtime entities, so, you can't have default implementations and make a runtime type check for the interface: https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChkHID0RyMmAFAJQBcyAzm[…]HR66CwUIBAA7iboFtbUyKCMcCBI6DBRVMSkMvE+lhAIYMDeqlDqUEA
So, if we will allow to use implements from TS, it will break all the runtime type checks for the interface and their implementations will lose all the default implementations.

[Edoardo Luppi]

Thanks for the explanations.
So basically even if we are JsExport-ing interfaces, we can't really use them from the TS side.

[Artem Kobzar]

Technically we can just provide the types hierarchy: if you export an interface and a class which implements the interface, you can use the interface as a type to not bind your TS to a specific implementation of the interface

[Edoardo Luppi]

And what'a the worst case scenario if I let a TS consumer implement the interface and pass it in a K/JS transpiled object? (apart from type checking not working)

[Edoardo Luppi]

Well I guess if type checking doesn't work, it will just throw whatever JS error it uses at runtime.

[Edoardo Luppi]

@Artem Kobzar sorry Artem, one last related question: is this workaraundable somehow? Like, what if a TS implementer passes by an exposed Kotlin function, would I be able to properly transform a pure JS object into a valid KT one?

[Artem Kobzar]

I don't feel like right now it's possible, but we are thinking about different approaches so that it may be an option soon.

[Edoardo Luppi]

Thanks Artem. Currently I don't think I have that use case, but since the KJS project is still in evaluation phase, they may ask me if there is way to keep the core MVP in Kotlin, and let other people write in TS for a productivity comparison.

[Edoardo Luppi]

Found an issue in YouTrack. https://youtrack.jetbrains.com/issue/KT-56618
This seems to describe my possible use case, or it's very very similar on what it attempts to do.