A modern programming language that makes developers happier.

kotlinlang

Can I force the compiler to use `internal` classes from a library I have no control over? Or is that forever forbidden?

You can't. This is meaning of `internal` modifier. But if you want to do it very much then you can call `internal` from kotlin library from java code (java doesn't know anything about `internal` and see such declarations as `public`)

Well in Kotlin there’s this - likely problematic - hack :slightly_smiling_face:
```@Suppress("INVISIBLE_MEMBER", "INVISIBLE_REFERENCE")```


Please don't do that. We are planning to forbid error suppressing someday. And it won't be breaking change, so it may happen in any release when you won't expect that :ghost:

Hopefully not before making `kotlin.internal.*` annotations available publicly :stuck_out_tongue:

Oooooohhh I might actually do that :imp: (not for any shipped code, it's for hacking something quickly so I understand i'm voiding the warranty here :slightly_smiling_face:)

<@U1UQX3JCC> BTW which internal annotations you use in real life?

Mostly `LowPriorityInOverloadResolution` to resolve conflicts in DSL.
Sometimes `OnlyInputTypes` but I understood that it’s a workaround for a temporary compiler limitation.
Sometimes `InlineOnly` but I think I still don’t fully understand it.
I have used `NoInfer` and `Exact` in the past but have to check if I’m still doing so.

EDIT: Just checked.
• Plenty uses of `LowPriorityInOverloadResolution`.
• `OnlyInputTypes` only for custom `assert…` funs.
• Plenty of `InlineOnly` with the idea of reducing output size by allowing inline-only uses. Probably not working that way either.
• I don’t use any other internal annotations.

btw, regarding ignoring errors - I think I win with longest list of suppressions in the name of DSL &amp; performance :sweat_smile:

<https://github.com/fluidsonic/fluid-react/blob/main/sources-js/RBuilder.kt>

Kotlin adds so much overhead in JS files that I use every trick I can find to reduce its footprint.

<@UKPEELJCW> Kotlin/JS now contains many redundant limitations, which don’t allow to represent existed  external contracts. Most known described in <https://youtrack.jetbrains.com/issue/KT-42871|KT-42871> . But this list isn’t full! New library - new suppresses!

&gt; We are planning to forbid error suppressing someday.
For now it’s death for non-`leftpad` declarations (for `stdlib-js` too)

&gt; We are planning to forbid error suppressing someday.
This will happen only after we fix all cases where such suppression are needed and there is no workaround with other language constructs

<@UKPEELJCW> does that also include then the usecase for suppressing the "Bounds are not allowed for type parameter if bound by another type parameter"? because yes while @InlineOnly functions get that treatment (assuming that @InlineOnly is made public), there are other non-inline functions that might want to use that while sacrificing Java callability

There is a ticket for this feature already: <https://youtrack.jetbrains.com/issue/KT-33262>
And I think it can be implemented sometime