For AI agents: the complete documentation index is available at /tc39-atlas/llms.txt, the full documentation bundle is available at /tc39-atlas/llms-full.txt, and this page is available as Markdown at /tc39-atlas/proposals/stage/1/proposal-bigint-from-exponential.md.
TC39 Atlas
  • 简体中文

      • Bigint from exponential S1

      中文标题：从指数表示法创建 BigInt

      提案概览
      提案速览

      该提案解决了从指数表示法字符串创建 bigint 的不便，目前需要手动解析。它建议对静态情况提供语法支持，如 1e6n，并通过扩展 BigInt() 或添加 BigInt.parse() 等 API 来支持动态情况。它包含与其他语言的比较以及 npm 包中的先例。

      Note

      以下 README 来自上游仓库，其中的阶段或状态标注可能滞后；当前信息以提案概览为准。

      从指数表示法创建 BigInt

      状态

      提案发起人：Richard Gibson（@gibson042）

      阶段：1

      动机

      指数表示法在处理大整数时很有用，但目前不能直接用于定义 bigint。

      使用 _ 分隔符有所帮助，但对于足够大的值来说还不够。 手动转换是可能的（例如，/^(?:(0|[1-9][0-9]*)(?:[.]([0-9]*))?|[.]([0-9]+))(?:[Ee]([+-]?[0-9]+))?$/ 可以验证并匹配相关的整数部分/小数部分/十进制指数部分），但既繁琐又笨重。

      使用场景

      这个问题是在 Amount 提案中发现的，但在其他地方也会出现（例如，在解析像 { "scale": 1e6 } 这样的 JSON 时，需要访问源代码文本，或者处理货币、日期或时间时）。

      许多使用场景是静态的，即指数表示法是源代码文本的一部分，而其他场景是动态的，因此需要内置函数。

      描述

      对静态使用场景的支持可以通过语法提供，例如 1e6n。 如果是这样，这可能在广泛使用的编程语言中是前所未有的（参见 https://github.com/tc39/ecma262/pull/3857#issuecomment-4960986324）。

      对动态使用场景的支持可以通过扩展 BigInt("1e6") 的行为来实现，如 https://github.com/tc39/ecma262/pull/3857 所建议的，或者通过类似 BigInt.parse("1e6") 或 BigInt.fromString("1e6") 的方式。 注意，前者可能意味着运算符行为也需相应改变，例如 1_000_000n == "1e6"、1_000_000n <= "1e6" 和 1_000_000n >= "1e6"，就像 Number 的对应情况一样（1_000_000 == "1e6"、1_000_000 <= "1e6" 和 1_000_000 >= "1e6"）。

      动态使用场景涵盖了静态使用场景，尽管这会降低开发者体验和实施者的满意度。

      先例

      一些 npm 包已经支持将指数表示法的字符串解析为任意精度整数（或类似的字符串）：

      此外，还有更多任意精度十进制库，它们将这些行为推广到了整数之外。

      在其他编程语言中，.NET 的 BigInteger.Parse(str, options) 支持 AllowDecimalPoint 和 AllowExponent 选项，但这似乎是极限了：

      语言/API前导 +/-包裹空白基数前缀
      （例如 0x）      		分隔符
      （例如 _）      		小数点/指数
      Go (new(big.Int)).SetString(str, 0)是否是是否
      Java new BigInteger(str, radix)是否不适用否否
      JavaScript BigInt(str)是是是否否
      .NET BigInteger.Parse(str, options)可选可选否可选可选
      Python int(str, base=0)是是是是否
      Rust num_bigint from_str_radix(&str, radix)是否不适用是否

      作为背景，ECMAScript 在严格性方面是不同寻常的：

      语言/API浮点数 → 任意精度整数
      Go (*big.Float).Int(new(big.Int))向零截断
      Java bigDecimal.toBigInteger()向零截断
      JavaScript BigInt(flt)拒绝非整数
      .NET new BigInteger(flt)向零截断
      Python int(flt)向零截断
      Rust num_bigint from_f64(flt)向零截断

      演示历史

      实现

      Polyfill/转译器实现

      暂无。

      原生实现

      请在 Stage 2.7 之后查看。

      常见问题解答

      问：动态解析是否也应支持 _ 分隔符？

      答：不要通过 BigInt(string)，但也许可以通过另一个 API。

      问：动态解析是否应该可配置？

      答：待定。