为什么kotlin.math多数函数未提供Long类型参数与实现？

我使用Kotlin开展开发工作已有两年有余。
回顾这两年的开发经历，我发现自己调用kotlin.math包下的函数时，过于频繁地使用(num.toDouble()).toLong()的写法做类型转换，例如Math.sqrt(num.toDouble()).toLong()。我参与的两个项目中，团队都在工具类中封装了sumByLong()扩展函数——因为Kotlin标准库仅提供返回Int类型的sumBy与返回Double类型的sumByDouble，但项目中大量业务场景需要使用Long类型处理数据。

简言之，在我个人的开发场景中，基于Long类型的数学运算使用频率比Double、Float类型更高，但Long类型在Kotlin标准库中的支持覆盖范围非常有限。此外由于kotlin.math与java.lang.Math存在设计差异，并不推荐混合使用两者。

查阅kotlin.math官方文档可以发现，除abs、min、max三个函数外，其余所有函数都仅提供Float和Double类型的实现。

我希望有人能以通俗易懂（适合5岁儿童理解）的方式解释这一设计背后的实际原因，不要给出“开发者偷懒”“代码越多工作量越大”这类在搜索引擎结果中随处可见的无意义回答。

补充说明 #

• 我理解多数数学运算的返回值会是浮点数，我提出的疑问也包含函数参数未提供Long类型对应版本的问题。或许举Math.sqrt的例子不够恰当，math.log、math.cos这类函数更具代表性：这类函数本身就预期返回浮点数，但入参甚至不支持Int类型。
• 我之前提到“Long比Double使用更普遍”是基于我个人两年的Kotlin开发经验，并非指代所有开发者的通用使用场景，为此前表述不够清晰致歉。

通俗解释 #

你可以把Kotlin标准库想象成小区门口开了很多年的便民小卖部，所有摆货逻辑都是老板摸透了周边住户的习惯定的：

1. 核心货架永远摆绝大多数人都要用的货。kotlin.math里的三角函数、对数、平方根这类函数，从诞生之初就是服务于科学计算、图形计算、工程计算这类场景的，这类场景下大家默认用小数（Float/Double）做计算——就像你去小卖部买散称的糖果，秤永远显示几点几克，不会给你报整克的整数。99%的人用这些函数的时候本来就传小数，所以老板直接把小数版本的货摆在进门最顺手的位置，不用找就能拿到。
2. 不会为了小众需求重复摆货。如果给Int、Long、Short、Byte所有整数类型都做一遍入参重载，本质上就是把同一款矿泉水，分别给1米2、1米5、1米8的人做三个高度的拿取口——完全没必要。不管你传什么整数类型，转成Double的操作几乎没有额外性能损耗，写起来也只是多几个字符的事。如果硬要做所有整数类型的重载，平白多出来几百行几乎重复的代码，后续修bug、加新功能的时候要同步改四五份逻辑，反而更容易出问题。
3. 业务场景的个性化需求不会放进通用货架。你在业务开发里常用的Long类型求和、整数开方取整这类需求，本质是特定业务场景的计数、统计需求，不是所有人都要用的通用数学能力——就像你自己在家攒弹珠要数总数，小卖部不会专门卖数弹珠的专用小盒子，毕竟有人攒弹珠、有人攒卡片、有人攒积木，每个人的计数需求都不一样，自己在家花两分钟做个小盒子用着最顺手。这也是为什么几乎所有做业务开发的Kotlin团队，都会自己写sumByLong这类简单的扩展函数，写一次全团队永久复用，比把所有零散的小众需求都塞进标准库合理得多。
4. 不推荐和Java的Math类混着用的逻辑更简单：就像小卖部和街对面超市卖的同一款可乐，可能批次、包装细节不一样，来回跑着买容易拿混，固定用一个版本的就不会出莫名其妙的兼容问题。

标准库的核心设计逻辑从来不是“覆盖所有人的所有需求”，而是“把90%以上开发者在通用场景下都需要的能力做到最精简可靠”，剩下的个性化需求，用Kotlin的扩展函数自己实现，成本极低，也不会让标准库变得臃肿难维护。

内容的提问来源于stack exchange，提问作者Abhinav Kulshreshtha