https://kotlinlang.org logo
Join Slack
Powered by
``` inline fun <reified T : Any> myFunc() = ...
# announcements
m
Copy code
inline fun <reified T : Any> myFunc() = myFuncImpl(T::class)

internal fun <T : Any> myFuncImpl(clazz: KClass<T>) {}
#C0B9K7EP2 How about making this compile?
@marcinmoskala
o
Then the inline function needs to be internal as well
m
I know why it doesn't work.
o
Hmmm. So why is this a problem?
m
But 
internal
is actually 
public
on bytecode level, so it's "possible" to call it anyway from outside the library.
API looks better without exposing 
myFuncImpl
to the developer using 
myFunc
.
👍 1
o
I suppose, but is it really that important to keep it internal? I use this sort of pattern often, and I don't see any problem in having it public. Plus it makes sense from a Java interop perspective. How else would you call it from Java?
m
That's why it's a #C0922A726 question, not a direct #C0B9K7EP2 proposal.
o
I see
m
I was doing code review on a friends library.
And didn't like functions with 
clazz: KClass
protected as well as public API.
Cause you will never use them directly as a user of the lib.
m
I don’t like them either xP
o
Maybe they could be generated by the compiler somehow. In such a way that they are inaccessible from Kotlin code, but accessible from Java code. That would keep the Java interop intact, while not polluting the API from a Kotlin point of view
m
This is argument: Kotlin is not only Java, but also JS and possibly native in future 😕
o
I am not sure if the same interop problem applies in JS. Maybe someone with more KotlinJS experience can confirm?
m
I don’t want to sound like I am against it. I support making internal accessible in public inline functions. I think that discussion should be about how it should work, not what can we do in what platform. But thinking ahead if it won’t cause the problems might be helpful.
i
If you want to call internal api from public inline function, you need to annotate it with 
@PublishedApi
annotation. This will make it effectively public.
o
oooh
p
Hmm seems to be not working as well 😛
o
It's working fine for me
I didn't know this was possible.
p
It says is only for internal declaration
m
You learn every day 🙂
o
@pavlospt you put the annotation on the internal function
p
so on the override inline fun <reified T>
right?
o
Are we talking about the same thing?
p
I have a method called 
getFoo
that is overriden
ok?
so it’s final form is: 
override inline fun<reified T> getFoot() : T {}
do i need to annotate this one?
o
Let's move this discussion to another thread. I think you're talking about the issue you posted about previously.
i
@pavlospt, I was answering to @mg6maciej's question that was in the beginning of this thread
m
@ilya.gorbunov Thanks for the annotation. What's the impact of using it? Will the 
internal
function be visible to users of the library? a) In Java or b) in Kotlin?
o
a) yes I have tested it
b) I don't think so, because then why make it internal in the first place?
m
Ok. Cool.
Is the name mangled?
o
in Java?
in Java, no. The name doesn't have to be changed by the compiler because the inline function is not visible in Java anyway
m
Makes sense. Thanks.
😁 1
i
The name of the member with such annotation must not be mangled. There was some bug though in 1.1.0 with property accessors being mangled, but is has been already fixed in 1.1.1
Open in Slack
PreviousNext
Powered by