Inlining for property accessors

[abreslav]

Proposal

[yole]

I think the proposal lacks a motivation section. As we all know, the inline modifier for function is not a performance tool, because HotSpot does a great job of inlining (and AFAIK it has special logic for inlining property accessors). For functions, its main benefits are inlining lambda parameters and associated benefits (non-local returns), as well as reified type parameters. Neither of these are applicable to property accessors. So: why?

[Takhion]

Android, for example, benefits greatly from inlining!

[udalov]

For functions, its main benefits are inlining lambda parameters and associated benefits (non-local returns), as well as reified type parameters. Neither of these are applicable to property accessors.

In fact, reified type parameters will now be applicable to property accessors:

inline val <reified T : PsiElement> T.nextSiblingOfSameType: T?
    get() = PsiTreeUtil.getNextSiblingOfType(this, T::class.java)

Another motivation, as with functions, is to hide some properties from the binary interface of a library. In Kotlin standard library, together with the @InlineOnly annotation this might make it possible in the future to exclude declarations of such properties from class files, reducing method count.

[yole]

Sounds great! Now let's add it to the text of the KEEP :)

[Jire]

I'm very excited for reified in properties!

[konsoletyper]

What about member properties? Can they be inlined in case they are neither open nor override?

[abreslav]

@konsoletyper If they have no backing fields, the rules should be the same as for functions. Fields are problematic on the JVM because they are private. // cc @max-kammerer

[eygraber]

This would be nice to move an extension function I have to a property (which would make more sense as a property)

inline fun <reified T : Any?> T.TAG()
    = ((this as? Any)?.javaClass?.simpleName ?: "${T::class.simpleName ?: "null"}?").replace("CompanionObject", "")

[fab1an]

I found performance-critical loops using for (i in 0..list.lastIndex where JMH profiling showed the slowest method call being lastIndex

[dzharkov]

The feature has been released in Kotlin 1.1, thus I'm closing the KEEP. Do not hesitate to open a YouTrack issue for any additional suggestions.