https://kotlinlang.org logo
#announcements
Title
# announcements
m

mg6maciej

03/17/2017, 8:37 AM
Copy code
inline fun <reified T : Any> myFunc() = myFuncImpl(T::class)

internal fun <T : Any> myFuncImpl(clazz: KClass<T>) {}
#language-proposals How about making this compile?
@marcinmoskala
o

okkero

03/17/2017, 8:40 AM
Then the inline function needs to be internal as well
m

mg6maciej

03/17/2017, 8:41 AM
I know why it doesn't work.
o

okkero

03/17/2017, 8:42 AM
Hmmm. So why is this a problem?
m

mg6maciej

03/17/2017, 8:42 AM
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

okkero

03/17/2017, 8:44 AM
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

mg6maciej

03/17/2017, 8:45 AM
That's why it's a #general question, not a direct #language-proposals proposal.
o

okkero

03/17/2017, 8:46 AM
I see
m

mg6maciej

03/17/2017, 8:47 AM
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

marcinmoskala

03/17/2017, 9:20 AM
I don’t like them either xP
o

okkero

03/17/2017, 9:45 AM
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

marcinmoskala

03/17/2017, 9:47 AM
This is argument: Kotlin is not only Java, but also JS and possibly native in future 😕
o

okkero

03/17/2017, 9:50 AM
I am not sure if the same interop problem applies in JS. Maybe someone with more KotlinJS experience can confirm?
m

marcinmoskala

03/17/2017, 10:07 AM
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

ilya.gorbunov

03/17/2017, 2:38 PM
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

okkero

03/17/2017, 2:39 PM
oooh
p

pavlospt

03/17/2017, 2:40 PM
Hmm seems to be not working as well 😛
o

okkero

03/17/2017, 2:40 PM
It's working fine for me
I didn't know this was possible.
p

pavlospt

03/17/2017, 2:41 PM
It says is only for internal declaration
m

mg6maciej

03/17/2017, 2:41 PM
You learn every day 🙂
o

okkero

03/17/2017, 2:41 PM
@pavlospt you put the annotation on the internal function
p

pavlospt

03/17/2017, 2:42 PM
so on the override inline fun <reified T>
right?
o

okkero

03/17/2017, 2:42 PM
Are we talking about the same thing?
p

pavlospt

03/17/2017, 2:43 PM
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

okkero

03/17/2017, 2:45 PM
Let's move this discussion to another thread. I think you're talking about the issue you posted about previously.
i

ilya.gorbunov

03/17/2017, 2:45 PM
@pavlospt, I was answering to @mg6maciej's question that was in the beginning of this thread
m

mg6maciej

03/17/2017, 2:46 PM
@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

okkero

03/17/2017, 2:46 PM
a) yes I have tested it
b) I don't think so, because then why make it internal in the first place?
m

mg6maciej

03/17/2017, 2:47 PM
Ok. Cool.
Is the name mangled?
o

okkero

03/17/2017, 2:47 PM
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

mg6maciej

03/17/2017, 2:49 PM
Makes sense. Thanks.
😁 1
i

ilya.gorbunov

03/17/2017, 2:56 PM
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