Just of curiosity: Why is

ceil()

not an extension on Double?

You're rounding the number, the number isn't rounding itself

Ah, thanks.

one might expect extra jvm autobox penalties on delegates to Number hierarchy not that it isn't tempting to have a lot of sugar around

none of the

kotlin.math

functions operate on generic

Number

, only concrete

Int

Long

Float

Double

primitive types

context is important. delegates work on vtables; HashSet<Int> is simply not going to be the same as eclipse IntHashSet

that's true, but how is that related to this thread?

one might expect extra jvm autobox penalties on delegates to Number hierarchy, period, under all circumstances, using the jvm. kotlin or otherwise.

the existence of Number has no bearing on any of these functions and extensions

a more interesting point is that syntactic sugar increases the evaluation size of inlining/EA candidates toward the tiny default threshold set for java language. doubleIterator.map{it.ceil()} <--- requires extra love.

DoubleIterator.map

is neither inline, and even if it were, it is not specialized so https://youtrack.jetbrains.com/issue/KT-29460 results in boxing. so that still makes no difference

srcDoubleArray.let{src->DoubleArray(src.size){ceil(src[it])}} stands a better chance than most things to minimize boxing if ceil is just aliased from java.