``` inline fun test(vararg properties: Pair<Str...

# announcements

[Marc Knaup]

inline fun test(vararg properties: Pair<String, Any?>) {
   //(uses pairs)
}

test(
   "a" to 1,
   "b" to 2,
   …
)

Can the compiler optimize away the Pair allocations and maybe even the boxing?
if so, is inline needed for that to happen?

[spand]

I doubt it can avoid the allocations but they should be fairly cheap since they are so shortlived (on the jvm).

[gildor]

Agree with Johannes, I don’t think that compiler can optimize it even in theory, this is object and can be passed somewhere else, even if you inline all the pairs and you code allows that, but than change your code so inlining become impossible, such change become binary incompatible (because function will have different signature on byte code level)

[Marc Knaup]

The binary incompatibility problem you always have with inline functions. If the function is in the same module that shouldn't matter much (which it is in my case).

And the compiler should know if the object is passed anywhere else because the function is inlined.
OTOH it would change the function resolution and Int.toString() would suddenly be used instead of Integer.toString() which may come unexpected 🤔

[gildor]

The binary incompatibility problem you always have with inline functions

It’s not true. Because if you call such function from Java you actually call common, non-inline function (which also exist in your bytecode)

[Marc Knaup]

Ah okay.
Will these functions be used at all if you don't write anything in Java anymore?
Oh, I just saw that you can inline overridden functions 😅

[gildor]

And also if you restrict reflection access

[gildor]

I mean in general probably such optimization possible with some limitations, but because of edge cases and probably really complicated static analysis ti doesn’t worth to do

[gildor]

and instead use those resources on development of Value Types which solve problem of allocations for such cases

[gildor]

But I’m not really familiar with compilers development or even Kotlin implementation , so consider all my comments just as speculation on this topic, I may be completely wrong 🙈

[Marc Knaup]

Oh, value types are being worked on? That's awesome!
Thank you for your explanations 👍

[gildor]

value types are being worked on

As I know nothing will happen until Java will not stabilise implementation details, so Kotlin can develop own value types based on this to be compatible with future version of JVM with value types

[gildor]

If you really so worry about performance for this particular case, just pass Array<Any> and use odd elements as keys and even as values (with casting) in your function, not type safe, but will have the same performance as your inline-pairs optimization

[Marc Knaup]

True, but not worth the lost safety. Was just curious how far the compiler can go because if I recall correctly mapOf for example does get rid of the `Pair`s. But I could be wrong.

[gildor]

mapOf for example does get rid of the `Pair`s

it’s not true, there is no optimization as I know

[gildor]

but yeah, it’s probably possible for mapOf