【问题标题】：Why BigInt demand explicit conversion from Number?为什么 BigInt 要求从 Number 显式转换？
【发布时间】：2020-01-19 15:45:05
【问题描述】：

BigInt 和 Number 转换

在 JavaScript 中处理数字时，有两种基本类型可供选择 - BigInt 和 Number。可以预期从“smaller”类型到“bigger”类型的隐式转换，这在 JavaScript 中不是这种情况。

预期

当计算 BigInt 和 Number 的某种组合时，用户可能会期望从 Number 到 BigInt 的隐式转换，如下例所示：

const number = 16n + 32; // DOESN'T WORK
// Expected: Evaluates to 48n

实际行为

在 BigInt 和 Number 上运行的表达式都抛出错误：

const number = 16n + 32; 
// Throws "TypeError: Cannot mix BigInt and other types, use explicit conversions"

为什么上述情况需要显式转换？

或者换句话说，这种设计背后的原因是什么？

【问题讨论】：

一个动机也可能是速度。强制是有代价的。如果 V8 或任何 Javascript 引擎可以强制执行typeof value = 'bigint'，则不需要额外检查。

标签： javascript bigint ecmascript-next

【解决方案1】：

这记录在原始 BigInt 提案中：https://github.com/tc39/proposal-bigint/blob/master/README.md#design-goals-or-why-is-this-like-this

当出现混乱的情况时，这个建议倾向于抛出异常而不是依赖类型强制，并冒着给出不准确答案的风险。

【讨论】：

打败我吧 :) 不过我还是不太喜欢他们模糊的动机。我很想看到一个假设它可能出错的实际示例。

【解决方案2】：

这是一种设计选择。在静态类型语言中，强制转换可能会丢失信息，例如从浮点数转换为整数，小数部分会被截断。 JavaScript 确实类型强制，您可能期望 16n + 32 只使用 32 就好像它是 BigInt 而不是 Number 并且不会有问题。这纯粹是一个设计选择，在this part of the documentation

【讨论】：

【解决方案3】：

它们不是“更小”和“更大”。一个有真实但可能不精确的数字，另一个有整数但精确的数字。你认为16n + 32.5 的结果应该是什么？（请注意，在类型方面，32 和 32.5 之间没有区别）。自动转换为 BigInt 会丢失任何小数值；自动转换为 Number 将面临精度损失和潜在溢出的风险。显式转换的要求迫使程序员选择他们想要的行为，而不是将其作为潜在的（非常可能的）错误来源。

【讨论】：

【解决方案4】：

您可能错过了重要的一点：
BigInt 是关于整数的
Number 是关于实数的
从 32 到 32n 的隐式转换可能有意义，但从浮点数的隐式转换例如1.555 到 BigInt 会产生误导。

【讨论】：