Just of curiosity: Why is `ceil()` not an extensio...

# stdlib

[holgerbrandl]

Just of curiosity: Why is ceil() not an extension on Double?

[CLOVIS]

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

[CLOVIS]

Extension functions mean “this object can do [...]”, but rounding is something that happens to a number, not really something a number does

[holgerbrandl]

Ah, thanks.

[jimn]

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

[ephemient]

none of the kotlin.math functions operate on generic Number, only concrete Int Long Float Double primitive types

[ephemient]

val Double.absoluteValue doesn't box

[jimn]

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

[ephemient]

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

[jimn]

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

[ephemient]

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

[jimn]

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.

[ephemient]

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

[ephemient]

now, if you were talking about a hypothetical specialized DoubleIterable.map, that could be different… but it also doesn't exist

[jimn]

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.