madvur.blogg.se - Internal fun kotlin

It’s common to use inlining in the API (e.g.

make compilation fail if tried to access it from a non-private scope.

remove auto completion from non-private scope (just like for a private members).

make an function/field accessible only privately.

If we don’t want to use the private keyword, I’d personally be happy with a annotation that has similar effect to + annotation, namely it should: I’m no expert of binary compatibilty issues, but wouldn’t it possible to just make the private method public during compilation (failing compilation if someone uses the “supposely private” API directly)?Ī workaround that I currently use is to use with level error to make the use of the “supposely private” API more alerted for the user, but it’s cumbersome to do it every time.

Also note that mangling does not happen for internal top-level functions because inheritance is not possible there.

Interoperability with the Java language is not relevant here. This way, you can have a public base class in one module, a public derived class in another module, and they both can have an internal fun foo() which will not be overridden at runtime because their JVM signatures are different. Internal functions in classes have mangled names to reduce the chances of accidental override of unrelated declarations in public classes on JVM. In this article someone said that internal functions in kotlin have mangled names to make them harder to use from java. I agree with the initial idea though, and supporting for private functions IMHO would make sense. In fact, unfortunately the compiler already works in such a way that if it’s tricked (because of some bug) into generating a private declaration reference in a public inline function, it does so via a synthetic accessor, and that leads to uncomfortable binary compatibility problems (e.g. Even if synthetic accessors are used, the accessor’s name still depends on the name of the declaration and there’s no way to customize it. This wouldn’t work very well because you’d have no indication in the sources that a private declaration is used from a declaration that is inlined into the client code, so you could accidentally rename it and break the clients. And this scenario could be easily implemented by the compiler by creating synthetic accessors - very old technique used already in other similar cases.